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Vorwort 



Ziel der Deutschen Gesellschaft für Operations Research (DGOR) e.V. ist es, 
Operations Research (Unternehmensforschung) in Wirtschaft, Wissenschaft 
und in Verwaltung zu fördern und zu verbreiten. Dabei orientiert sie sich 
nicht nur an der im klassischen Sinne verstandenen Thematik, sondern 
befaßt sich auch mit den Themen, die im weiteren Sinne mit der Unter- 
nehmensforschung verknüpft sind. Ausdruck dieser Orientierung sind zahl- 
reiche Arbeitsgruppen mit entsprechender Themenstellung, so z.B. die Ar- 
beitsgruppen "Personal Computing" und "Wirtschaftsinformatik". Mit den 
Arbeitsgruppen soll ein Forum angeboten werden, den Transfer von Wissen 
und Erfahrungen zwischen Theorie und Praxis zu fördern. 



Wirtschaftsinformatik als interdisziplinäres Fachgebiet zwischen Wirtschafts- 
wissenschaften und Informatik (entsprechend der fortschreitenden Entwick- 
lung der integrierten Fertigung (CIM) bestehen auch zunehmend interdiszi- 
plinäre Überschneidungen mit den Ingenieurwissenschaften) befaßt sich mit 
dem Entwurf, der Entwicklung und dem Einsatz von Anwendungs- und 
Kommunikationssystemen in Wirtschaft und Verwaltung. Dabei sind die 
Prinzipien, Methoden, Modelle und Werkzeuge zu betrachten, die hierbei 
eingesetzt werden. Die Arbeitsgruppe "Wirtschaftsinformatik" nimmt hierzu 
aktuelle Themenstellungen auf, wobei sie - bedingt durch den heterogenen 
Teilnehmerkreis aus Banken, Handel, Industrie, Verwaltung und Wissen- 
schaft - branchenspezifische Problemstellungen nur sekundär betrachtet. 
Theorie und Praxis sind in der thematischen Orientierung gleichgewichtig 
vertreten. 

Mit dem Rahmenthema "Operations Research und Wissensbasierte Systeme" 
sollte den Fragen nachgegangen werden, die sich aus den konkurrierenden 
Ansätzen der Modelle des Operations Research und Wissensbasierter Systeme 
ergeben, zumal festzustellen gilt, daß Wissensbasierte Systeme bzw. Experten- 
systeme zunehmend für Anwendungsfelder entwickelt werden, zu denen 
bereits ausgereifte Operations-Research-Modelle mit effizienten Algorithmen 
existieren. 

Aus der historischen Perspektive gilt zu fragen, ob die Modelle des Ope- 
rations-Research, die in den sechziger und siebziger Jahren eine dominante 
Position eingenommen hatten, nun mit Beginn der achtziger Jahren abgelöst 
werden von Wissensbasierten Systemen, die aus der Entwicklung der Künst- 
lichen Intelligenz (KI) hervorgegangen sind. Offensichtlich werden durch 
Wissensbasierte Systeme neue Qualitäten der Modellbildung eröffnet, die sich 
zunehmend deutlicher abzeichnen, deren Mächtigkeit sich aber derzeit nur 
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erahnen läßt. Daraus läßt sich jedoch nicht der Schluß ziehen, daß die Modelle 
des Operations-Research mit ihren methodischen Ansätzen und Lösungs- 
qualitäten ihre wissenschaftliche Bedeutung und praktische Relevanz ver- 
loren haben; im Gegenteil, Operations-Research erlebt derzeit in Forschung, 
Entwicklung und Anwendung eine Renaissance. Eine Ursache läßt sich auf 
den Innovationsschub zurückführen, der sich in der Informatik (insbesondere 
in der Informations- und Kommunikationstechnologie) vollzogen hat, denn 
durch Datenbanken, Workstations, Rechnerkapazitäten und -geschwindigkei- 
ten, Rechnemetze und Transputer stehen leistungsfähige Komponenten zur 
Verfügung, auf die man in den sechziger und siebziger Jahren nicht zurück- 
greifen konnte. So kann z.B. die Datenakquisition, die früher oftmals Pro- 
bleme bereitet hat, umfassend und abgesichert betrieben werden, und durch 
massiv paralleles Rechnen werden Bearbeitungszeiten möglich, die sich z.B. 
von Stunden auf Minuten reduzieren lassen. Umgekehrt sind Modelle des 
Operations Research die Grundlage für zahlreiche Forschungen, Entwick- 
lungen und Anwendungen in der Informatik. So werden z.B. durch Modelle 
der ganzzahligen Programmierung optimale Layouts für Chips entwickelt, 
und für verteilte Systeme werden Zuordnungsalgorithmen eingesetzt. 



Mit dem vorliegenden Buch werden teilweise die Referate wiedergegeben, die 
auf den Sitzungen der Arbeitsgruppe "Wirtschaftsinformatik" zum Rahmen- 
thema "Operations Research und Wissensbasierte Systeme" gehalten wurden. 
Sie zeigen Modellbildungen, Perspektiven sowie praxisbezogene Entwick- 
lungen imd Erfahrungen zu aktuellen Problemstellungen auf unterschied- 
lichen Anwendungsfeldern. 

Den Referenten sei nochmals herzlich gedankt, insbesondere für die schrift- 
liche Fassung ihres Vortrages. Ebenso herzlichen Dank gebührt den Gast- 
gebern der Sitzvmgen: dem Wissenschaftlichen Zentrum der IBM, Heidelberg, 
sowie der Sektion Wirtschaftswissenschaften der Karl-Marx-Universität, Leip- 
zig, in Kooperation mit der Lufthansa/Interhansa AG. 



Bonn, im Januar 1991 



Rainer Busch 
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Operations-Research-Modelle und Expertensysteme 
als Wissensmodule 



intelligenter Decision-Support-Systeme 



Prof. Dr. Rainer Busch 
Postfach 1250, Universitätsstr. 150 
4630 Bochum 1 



Abstract 



Die zahlreichen Expertensysteme, die bisher entwickelt wurden, zielen sehr 
häufig auf Anwendungsfelder ab, zu denen bereits ausgereifte Operations- 
Research-Modelle und effiziente Algorithmen existieren, die bekanntlich ihre 
Lösungsqualitäten bereits nachgewiesen haben. Es gilt daher zu untersuchen, 
ob und inwieweit sich Operations-Research-Modelle und Expertensysteme in 
den Modellansätzen und damit auch in ihren Einsatzmöglichkeiten unter- 
scheiden. Dabei zeigt sich, daß sie trotz unterschiedlicher Modellphilosphien 
und daraus resultierenden Modellqualitäten als "Problemlöser" (Solver) ein- 
gesetzt werden, d.h. sowohl Operations-Research-Modelle mit ihren fixen 
Strukturen als auch Expertensysteme mit ihren offenen Strukturen generie- 
ren Lösungen zu wohldefinierten Problemsituationen. Betrachtet man jedoch 
die individuelle Problemsituation eines Entscheidungsträgers, so zeichnet sie 
sich i.a. durch eine Vielzahl unstrukturierter, semi- und wohlstrukturierter 
Teilprobleme aus. Es ist daher notwendig, dem Entscheidungsträger zur 
Unterstützung seines Entscheidungsprozesses Werkzeuge bereitzustellen, die 
den Modellierungsprozeß im Rahmen seines individuellen Entscheidungs- 
kontextes ermöglichen. Es erweist sich deshalb als konsequent und sinnvoll, 
die Fähigkeit eines Expertensystems (Wissen zur Lösung von Problemen 
einzusetzen) extensiv zu nutzen und sie für Systeme verfügbar zu machen, 
die fähig sind, bei der Entwicklung von Modellen mit dem Benutzer "intelli- 
gent" zu interagieren. Dabei muß ein derartiges Modellierungs-Experten- 
system über eine Modell- und Methodenbank im Sinne einer Wissensbasis 
verfügen können. Hierzu bieten sich sowohl Operations-Research-Modelle 
mit ihren effizienten Algorithmen als auch Anwendungs-Expertensysteme 
mit ihren Lösungsstrategien als "Wissensmodule" an. 
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Bei dem inkrementeilen Prozeß der Modellierung gilt dann zu prüfen, ob xmd 
inwieweit zur individuellen Spezifikation des Benutzermodells die unter- 
schiedlichen Basismodelle und -methoden eingesetzt und bedarfsweise mit- 
einander verknüpft werden können. Bei einer Integration von Operations- 
Research-Modellen mit ihren effizienten Algorithmen und Anwendungs- 
Expertensysteme mit ihren Lösungsstrategien können sich die in den unter- 
schiedlichen Modellansätzen jeweils inhärenten Vorteile ergänzen und somit 
eine Basis bilden zur Entwicklung hochkomplexer, interdisziplinärer Modelle. 
Diese hohe Flexibilität in der Modell-Spezifikation und die Fähigkeit, auf die 
Entscheidungssituation des Benutzers eingehen zu können, sind die Grund- 
lage einer echten Interaktivität, die dem Benutzer rückgekoppeltes Lernen 
ermöglicht. Sie sind das Maß zur Bewertung "intelligenter" Dedsion-Support- 
Systeme. 



A. Einleitung 



Betrachtet man die zahlreichen Expertensysteme, die in den letzten Jahren 
entwickelt wurden, so ist auffällig, daß sie häufig auf Anwendungsfelder ab- 
zielen, zu denen bereits ausgereifte Operations-Research-Verfahren und ent- 
sprechende Software-Systeme existieren. So werden Expertensysteme und 
Optimierimgsverfahren z.B. eingesetzt 



- in der Produktion 

(für die Layoutplanung, Material- und Lagerwirtschaft, Produktions- 
planung und -Steuerung, Qualitätsprüfung, usw.) 

- im Vertrieb 

(für die Entwicklung von Konfigurationen - im Sinne einer Zusam- 
menstellung von Systemelementen als ganzzahliges oder gemischt- 
ganzzahliges Problem, für die Vertriebslogistik, usw.) 
für allgemeine Planungsaufgaben 

(zur Termin- und Reiseplanung, Personaleinsatzplanung, usw.) 



Es drängen sich daher die Fragen auf, ob z.B. Expertensysteme im Vergleich 
mit den existierenden Operations-Research-Verfahren lediglich Neuentwick- 
Itmgen bzw. Neugestaltungen zur gleichen Thematik darstellen, oder ob es 
Weiterentwicklungen sind, die neue Teilaspekte konsequent berücksichtigen 
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(so z.B. ein interaktives Systemverhalten), oder ob es alternative Systeme sind, 
die auf eine besondere Klasse von Modellansätzen (so z.B. Inferenz-Systeme) 
abzielen, oder beinhalten Expertensysteme grundsätzlich neue methodische 
Ansätze zur Modellbildung und führen somit über den Rahmen der Modelle 
und Verfahren des Operations-Research hinaus. In diesem Zusammenhang 
sind die Weiterentwicklungen der Basistechnologien (so z.B. Werkzeuge zur 
Software-Entwicklung, Datenbanken, Informations- und Kommunikations- 
technologie) in die Betrachtung einzubeziehen. 

Da es Ziel und Zweck sowohl der Operations-Research-Verfahren als auch der 
Expertensysteme ist, Entscheidungsunterstützung zu geben, bietet es sich an, 
aus dieser Zielorientierung heraus zu analysieren, welche Gemeinsamkeiten 
bzw. Unterschiede vorhanden sind. Dabei ist zu prüfen, wie und in welcher 
Form die Modelle dieser beiden Ansätze zur Entscheidungsunterstützung bei- 
tragen, d.h. es gilt zu untersuchen, welchen Beitrag Operations Research und 
Expertensysteme bei der Gestaltung von Decision-Support-Systemen (DSS) 
leisten. 



B. Operations-Research-Modelle 

Die charakteristischen Elemente der Modelle des Operations Research und 
deren Einsatz zur Entscheidungsunterstützung seien beispielhaft an einem 
Problem der Linearen Optimierung (LP-Problem) dargestellt. Dieses Problem 
ist charakterisiert durch 



X = (xi, X2, ... , Xn) 


: Vektor der Entscheidungsvariablen 


A*x ^ a 
B = b 

C ^ c 


: Nebenbedingxmgen 


i »X 


: Zielfunktion 


25, d e R”/ a e RS 
b e Rt, fi e R« 

A : (s X n) - Matrix, 


: Festlegtmg der Grundmenge für 

Parameter und Entscheidxmgsvariablen. 


B : (t X n) - Matrix, 
C : (u X n) - Matrix 
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Das zugrundegelegte Entscheidungsproblem wird durch ein formales, mathe- 
matisches xmd somit präzises Modell dargestellt, das durch algebraische, 
numerische Strukturen geprägt ist. Das Modell ist wohlstrukturiert, so daß das 
Entscheidungsproblem in feste, vorgeschriebene Strukturen gefaßt ist. Der 
Lösungsraum ist wohldefiniert. In der Praxis zeigt sich, daß im Interesse der 
formalen, vorgeschriebenen Modellstruktur bei der Entwicklung des Modells 
häufig eine starke Ausschnittbildung der Realität erforderlich ist. Diese for- 
malen Zwänge können ein isoliertes Problemdenken erzeugen. Die festen 
Modellstrukturen bedingen einerseits nur geringfügige Flexibilität, anderer- 
seits sind sie eine notwendige Grundlage für den Einsatz von Algorithmen 
zur Lösimgsermittlung. Die Lösung wird auf der Grundlage des formulierten 
Modells und des hiermit verknüpften Algorithmus automatisch erzeugt, d.h. 
der Entscheidungsträger hat keine Möglichkeit in den Lösungsprozeß einzu- 
greifen. 



Aus der Sicht des Benutzers, der Operations-Research-Modelle mit den zuge- 
hörigen Lösungsverfahren zur Entscheidungsunterstützung einsetzt, stellen 
sich diese Modelle bzw. Verfahren als sog. Solver dar, d.h. 

- das entwickelte Operations-Research-Modell hat Black-Box-Struktur, 
der Entscheidungsträger karm nicht auf das Modell einwirken, 

es werden algorithmische Lösungen von wohldefinierten Aufgaben- 
stellungen generiert, 

wegen starker Ausschnittbildung der Realität und geringfügiger Inte- 
grationsfähigkeit sind sie sog. stand-alone-Modelle, 

- der Entscheidungsträger wird weder bei der Modellierung noch bei der 
Entwicklung der formalen Struktur unterstützt, 

das Operations-Research-Modell wird von Spezialisten für Spezialisten 
entwickelt. 



Der Einsatz eines Solvers ist methoden-orientiert, denn durch den Einsatz 
einer oder mehrerer Methoden wird auf der Basis eines mathematischen 
Modells eine Lösung generiert, die dieses Modell vorgibt. Bei einem Einsatz 
zur Entscheidungsunterstützimg haben das Modell, die Methoden und somit 
auch die hieraus generierte Lösung einen normativen Charakter. Diese Ver- 
fahrensphilosophie - auf der Grundlage vergebener Daten mit einer festen, 
abgeschlossenen Modellstruktur durch einen vorgegebenen Verarbeitungs- 
mechanismus eine Lösung automatisch zu erzeugen - korrespendiert mit dem 
batch-orientierten Verarbeitungsprinzip der Rechnertechnologie der sechziger 




5 



Jahre. Das sog. EVA-Prinzip (Eingabe-Verarbeitung- Ausgabe) charakterisiert 
diesen sequentiellen, abgeschlossenen Prozeß. 



( ^ 

r/^rGAfiE VERARBElTUtIC AUSGABE 




(sog. prozcdurale Ansatz) 




V ^ 



Abb. 1: EVA-Prinzip und Operations-Research-Verfahren 



Auf der Basis des vorgegeben Verarbeitungsmechanismus des Operations- 
Research-Modells kann ein konventionelles Software-System entwickelt 
werden, das durch die Komponenten "Algorithmus und Daten" geprägt ist 
(prozeduraler Ansatz). Bei der Entwicklung des Software-Systems wird durch 
den Programmierer festgelegt, was auszuführen ist, und in welcher Reihen- 
folge es auszuführen ist, d.h. in dieser anweisungsbasierten Form wird die Se- 
quenz der Operationen/ Befehle imd Entscheidungen/ Abfragen ä priori fest- 
gelegt. Auf dieser Grimdlage wird ein übersichtlicher, aber starrer Kontrollfluß 
erzeugt. Der Verarbeitungsmechanismus, d.h. die Problemlösungsstrategie, 
und das Problemwissen, das durch das Modell repräsentiert wird, sind in 
einem konventionellen Software-System direkt miteinander verknüpft. 











6 



Mit der Veränderung der Rechnertechnologie vom Batch- zum Dialogbetrieb 
wurden Solversysteme durch eine interaktive Benutzerschnittstelle erweitert. 
Die anwendungsbezogene Schnittstelle des Software-Systems, z.B. in Form 
von Bildschirmmasken, eröffnet dem Benutzer einen flexiblen Umgang mit 
einem Solversystem, indem er die im Modell enthaltenen Parameter in ein- 
facher Weise spezifizieren kann. Das zugrundegelegte Modell und die darauf 
basierenden Lösungsverfahren können benutzt werden, ohne daß sich der 
Benutzer mit dessen formalen, mathematischen Strukturen auseinander- 
setzen muß. Der Benutzer wird somit in der Formalisierungsphase unter- 
stützt. Mit dieser interaktiven Benutzerschale wird der Solver auch für den 
Benutzer zugänglich, der nicht über das formale Wissen der Modellbildung 
verfügt. Das Operations-Research-Modell bleibt weiterhin eine Black-Box, d.h. 
der Benutzer/Entscheidungsträger kann nicht auf die Gestaltung des Modells 
einwirken. Das interaktive Zugangssystem vereinfacht lediglich die Ein- und 
Ausgabe. Es gibt keine Unterstützung bei der Modellbildung. Interaktive 
Solversysteme sind somit methoden-orientiert und nur für wohlstrukurierte 
Aufgabenstellungen einsatzbar. Das Software-System ist konventiell (proze- 
duraler Ansatz). 




V ^ 



Abb. 2: Interaktive Benutzerschnittstelle 



Diese Solver-Ansätze spiegeln das harte Systemdenken der fünfziger und 
sechziger Jahre wider. Dieses Denken setzt mit seinem ontologischen Ansatz 
voraus, daß die Realität aus gestaltbaren Systemen bestehe und die ent- 
wickelten Systemmodelle seien entsprechende Modelle der Realität. In diesem 
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Zusammenhang werden daher lediglich die strukturierten bzw. strukturier- 
baren Probleme betrachtet und unter Beachtung der Zielorientierung deren 
Lösung gesucht. Entsprechend dieser Philosophie können formale, mathema- 
tisch abgesicherte Lösungstechniken erfolgreich eingesetzt werden. Die for- 
male, mathematische Orientierung setzt i.a. den entsprechend ausgebildeten 
Spezialisten voraus. Durch die formalen Elemente der Modellbildung kann 
der Bezug zur eigentlichen Problemstellung bzw. Problemumgebung verloren 
gehen. 

Mit Beginn der achtziger Jahre hat sich dieses Systemdenken gewandelt, da 
man sich nicht mehr an geschlossenen Modellen als Abbildung der Realität 
orientiert. Das Systemdenken der achtziger und neunziger Jahre ist charak- 
terisiert durch einen epistemologischen Ansatz, da es Systemmodelle lediglich 
als intellektuelle Konstrukte betrachtet, mit deren Hilfe die Realität unter- 
sucht werden kann. Die entwickelten Modelle sind jeweils nur Approxima- 
tionen an die Realität und keine originalgetreuen Abbildungen. Mit diesem 
Ansatz ist das Modell offen für Erweiterungen bzw. Präzisierungen im Sinne 
der Problemstellung (evolutionärer Charakter). Als nachteilig erweist sich ein 
(möglicherweise) endloser Erweiterungs- bzw. Präzisiertmgsprozeß, da hierbei 
nur vorläufige und keine endgültigen Antworten erarbeitet werden. 



C. Expertensysteme 



Mit den Forschxmgsarbeiten auf dem Gebiet der Künstlichen Intelligenz sind 
seit Mitte der sechziger Jahre die Grundlagen gelegt worden, die einen 
weichen Systemansatz ermöglichen. Hierbei sind neue Ansätze für Software- 
Systeme initiiert worden, die auf eine Trennung der Problemlösungsstrategie 
und des Problem Wissens abzielen. Für derartige Systeme wurde 1977 der 
Begriff ''Expertensystem" eingeführt. Unter einem Expertensystem versteht 
man ein Software-System, das, bezogen auf eine wohldefinierte Aufgaben- 
stellung, die Spezialkenntnisse und die Schlußfolgerungsfähigkeit qualifi- 
zierter Fachleute (sog. Experten) nachbilden und verfügbar machen kann. 
Diese Spezialkenntnisse und die Nutzung durch Problemlösungsstrategien 
haben zunehmenden Stellenwert in der industriellen Praxis, da sie als 
bedeutender Produktivitätsfaktor erkannt werden. Hierin ist die große Nach- 
frage nach Expertensystemen begründet, da mit diesen Systemen das Wissen 
und die Lösungsstrategien abgebildet und zur Mehrfachnutzung verfügbar 
gemacht werden sollen. 
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Die wichtigsten Problemlösungstypen, die ein Expertensystem beinhaltet, sind 
Diagnostik und Konstruktion. Bei der Diagnostik (im Sinne von Auswahl 
bzw. Klassifikation) wird eine Lösung aus einer Menge vorgegebener Alter- 
nativen ausgewählt. Bei der Konstruktion (im Sinne von Konfigurierung, 
Design bzw. Planung) wird die Lösung aus den vorhandenen Grundelemen- 
ten (Bausteinen) zusammengesetzt. Darüberhinaus besteht die Möglichkeit 
der Simulation, indem aus einem vorgegebenen Ausgangszustand die Folge- 
zustände ermittelt und ihre Auswirkungen imtersucht werden. 

Die Struktur eines Expertensystems ist daher gekennzeichnet durch eine klare 
Trennung des Spezialwissens über das Aufgabengebiet (in formalisierter 
Form) und den Strategien, die zur Problemlösung eingesetzt werden können. 
Diese Trennung kann durch Implikationen bzw. Regeln ("wenn a, dann b") 
erzeugt werden. Damit wird in einem regelbasierten System (im Gegensatz zu 
einem konventionellem Software-System) durch den Experten lediglich fest- 
gelegt, was auszuführen ist. Die Reihenfolge der Ausfühnmgen wird durch 
den Regelinterpretierer bestimmt. 




Abb. 3: Anweisungs- und regelbasiertes Programmieren 



Durch diese offene Struktur ist der Kontrollfluß in einem Expertensystem 
zwar flexibel, aber auch unübersichtlich. Eine kontrollierte Nutzung großer 
regelbasierter Systeme kann sich hierdurch als äußerst schwierig gestalten, so 
z.B. bei nicht übersehbaren Nebenwirkungen. Diese Problematik wird zu- 
nehmend gelöst, indem man statt einer regelbasierten eine objektorientierte 
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Wissenspräsentation wählt. Damit wird ein fließender Übergang zu einem 
objektorientierten Programmierstil erzeugt. Die objektorientierte Sicht wird 
speziell für den Wissenserwerb genutzt. 

Da die Objekte und Zustände des Anwendungsfeldes durch spezielle Begriffe 
(Fachsprache) beschrieben werden, sind diese Begriffe beim Wissenserwerb zu 
sammeln. Dabei sind ihre Definitionen und ihre zueinander bestehenden 
Beziehimgen zu formalisieren. Die Objekte / Zustände des Anwendungsfeldes 
(sog. Agenten) können Nachrichten empfangen, sammeln und an andere 
Agenten versenden. Diese Nachrichten werden zur Lösung spezifischer 
Probleme genutzt. Mit dieser Verwendung der Daten zur Lösung spezieller 
Probleme imterscheiden sich Expertensysteme von Datenbanken, da bei der 
Benutzung einer Datenbank (Datenbankabfrage) die Daten ohne Verknüpfung 
auf eine vorgesehene Verwendung ermittelt werden. Daten werden somit 
von Wissen abgegrenzt. Der Übergang ist fließend. 




BENUTZER 



Erklirungs^ 

Komponente 



Interview^ 

Komponente 



Komponente 



fellspcziriMihi 

Wlasai 



ZwischencT^etmi 
^Problcmlösu ngi 



Wiwen 



Abb. 4: Basis-Architektur eines Expertensystems 
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Die offene Struktur eines Expertensystems ermöglicht eine aktuelle Wissens- 
basis, da diese Basis in relativ einfacher Weise verändert werden kann, indem 
Wissenselemente hinzugefügt, verändert oder gelöscht werden (Hexibilität). 
Expertensysteme können somit (im Gegensatz zu konventionellen Program- 
men) zur Lösung von Problem eingesetzt werden, deren Aufgabenstellung 
zumindest zu Beginn noch nicht klar definiert ("diffus") ist. Die aktuelle 
Wissensbasis und die Fähigkeit Probleme lösen zu können, ermöglicht die 
Simulation von Expertenwissen (Kompetenz des Systems). Dies setzt jedoch 
voraus, daß das sog. Expertenwissen formalisiert werden kann. Das benutzte 
Wissen wird durch die Konstruktionsprinzipien eines Expertensystems offen- 
gelegt. Die Lösung des Problems kann somit nachvollzogen werden (Trans- 
parenz). Die Nutzung des Expertensystems erfordert kein programmier- 
technisches Fachwissen (Benutzerfreundlichkeit). 



Die funktionale Trennung von Expertenwissen und Lösungsstrategie drückt 
sich in der Architektur des Systems durch die Trennung von Wissensbasis 
imd Steuersystem (sog. Expertensystem-Shell) aus. Das Steuersystem setzt sich 
zusammen aus einer 



Problemlösungskomponente, die das Expertenwissen interpretiert. 

Diese Komponenete entspricht dem Interpreter oder dem Compiler 
eines konventionellen Programms, das durch eine prozedurale Pro- 
grammiersprache geprägt ist. 

- Interviewkomponente, die den Dialog mit dem Benutzer steuert. 

Bei konventioneller Programmierung werden die Benutzerschnitt- 
stellen durch (i.a. interaktive) Eingabe- und Ausgabefunktionen 
realisiert. 

- Erklärungskomponente, die dem Benutzer die Vorgehensweise des Sys- 
tems xmd die hieraus ermittelte Lösung erläutert. Der Experte kann diese 
Komponente nutzen, um das System zu überprüfen und die Vorgehens- 
weise imd Lösung als korrekt zu bestätigen. Andernfalls kann er hiermit 
Fehler in der Wissensbasis lokalisieren. 

Diese Erklärungskomponente ist mit dem sog. Tracer (Pfad) eines 
konventionellen Programms vergleichbar. 

- Wissenserwerbskomponente, nüt deren Hilfe der Experte sein Wissen in 
das System einbringen bzw. ändern kann. 

Editor und Compiler sind die vergleichbaren Komponenten bei kon- 
ventioneller Programmierung. 
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Die Wissensbasis eines Expertensystems läßt sich nach der Herkunft des 
Wissens spezifizieren. Man unterscheidet 



- fallspezifisches Wissen, das sich aus dem spezifischen Faktenwissen des 
individuellen Problems eines Benutzers ableitet, 

- bereichsbezogenes Wissen, das durch fachspezifisches Faktenwissen und 
Kontrollwissen besteht sowie 

- Zwischen- und Endergebnisse (Lösungen) als Faktenwissen. 



Übertragt man diese Terminologie auf ein Lineares-Optimierungs-Problem, 
können die Nebenbedingungen des Modells als Wissensbasis interpretiert 
werden. Das gewählte Verfahren, z.B. das Simplex-Verfahren, entspricht der 
Problemlösungstrategie, wobei die zu ermittelnde Lösung durch die Ziel- 
funktion vorgegeben wird. 



Eine allgemeine Bewertung der Leistungsfähigkeit von Expertensystemen ist 
äußerst schwierig. Ein Ansatzpunkt kann über die derzeit existierenden Sys- 
teme gefunden werden. Hierbei reicht die Skala von sehr einfachen Experten- 
systemen mit einer flachen Struktur (so z.B. mehr oder minder "intelligente 
Auskunftssysteme") bis hin zu Systemen, die sich durch einen hohen Kom- 
plexitätsgrad auszeichnen. Bei hochkomplexen Expertensystemen besteht die 
Gefahr, nur noch (ebenso wie bei komplexen Operations-Research-Modellen) 
von ausgewählten Spezialisten verstanden und beherrscht zu werden. Diese 
Tendenz steht im Widerspruch zur Intention, Expertensysteme als Wissens- 
vervielfältiger einzusetzen. Die Konsequenz sind sog. Zugangs- und Abgangs- 
systeme, um die das Expertensystem erweitert wird. Mit speziellen Zugangs- 
systemen soll der Umgang mit dem hochkomplexen Expertensystem erleich- 
tert, eine fehlerfreie Nutzung ermöglicht und die Mächtigkeit des Systems 
voll ausgeschöpft werden. Mit einem entsprechenden Abgangssystem sollen 
die Ergebnisse dem nicht spezialisierten Benutzer erläutert und interpretiert 
werden. Diese Zusatzfunktionen können in die Erklärungskomponente inte- 
griert werden. 



Der Einsatzschwerpunkt von Expertensystemen liegt offensichtlich auf sog. 
diffusen Anwendungsbereichen, die sich mit formalen, meist mathemati- 
schen Modellen (so z.B. Operations-Research-Modellen) schlecht erfassen bzw. 
beschreiben lassen. Als vorteilhaft erweist sich die Möglichkeit einer dynami- 
schen Präzisierung der Wissensbasis, die u.a. durch ein empirisches Testen an 
Beispielobjekten erzielt werden kann. Dabei ist die Gefahr nicht zu verken- 
nen, daß - bedingt durch diese offene Struktur - u.U. mit dem Expertensystem 
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nur eine Folge von Zwischenlösungen generiert wird, die nicht notwendiger- 
weise konvergent ist. Als schwierig und im wesentlichen ungelöst ist eine all- 
gemeine, formale Darstellung von Wissen, d.h. die sog. Wissensaquisition 
muß sich auf die Anwendimgsfelder beschränken, deren Elemente sich for- 
mal darstellen lassen. 

In der Praxis hat sich gezeigt sich, daß bei Expertensystemen, ebenso wie bei 
Operations-Research-Modellen, die klassische Sicht der Entscheidens zugrun- 
degelegt wird, d.h. auf der Basis eines entwickelten Modells (im Sinne einer 
Menge heuristischer Regeln) werden durch Expertensysteme "richtige" Ent- 
scheidungen, d.h. Lösungen generiert. Expertensysteme haben somit (ebenso 
wie Operations-Research-Modelle) normativen Charakter. Im Rahmen einer 
Entscheidungsunterstützung ist daher zu prüfen, wie die unterschiedlichen 
Ansätze der Operations-Research-Modelle und der Expertensysteme in einem 
Decision-Support-System einzustufen sind. 



D. Fonnen der Entscheidungsunterstützung 



Betrachtet man die individuelle Problemsituation eines Entscheidungsträgers, 
so ist sie gekennzeichnet durch eine Vielzahl unstrukturierter, semi- und 
wohlstrukturierter Teilprobleme. So bezeichnet man ein Problem als wohl- 
strukturiert, wenn alle Komponenten des Problems / der Entscheidungssitua- 
tion sich formal beschreiben lassen, und der Lösungsraum, aus dem heraus 
Entscheidungsalternativen zu generieren sind, vollständig spezifiziert ist. 
Entsprechend sind die Kriterien zur Lösungsfindung bekannt. Sind diese 
Bedingungen nicht oder mu teUweise erfüllt, bezeichnet man ein Problem als 
unstrukturiert bzw. als semi-strukturiert. 

Zur Entwicklung eines problemadäquaten, individuellen Benutzer-Modells 
sind somit (insbesondere für die "weißen Flecken" der unstrukturierten 
Teilprobleme) Werkzeuge bereitzustellen, die eine Modellierimg / Gestaltung 
des Entscheidungsproblems in einfacher Weise unterstützen. Mit dieser 
Orientierung verlagert sich der Schwerpunkt der Betrachtimg von Modellen 
zu wohlstrukturierten Problemen hin zur individuellen Unterstützvmg einer 
gestaltbaren Entscheidungssituation. Es werden somit die subjektiven Krite- 
rien des Entscheidimgsträgers und der evolutionäre Charakter des Entschei- 
dvmgsprozesses in den Vordergrund gestellt. 



Da Operations-Research-Modelle und Expertensysteme zur Entscheidungs- 
imterstützung eingesetzt werden, gilt zunächst zu klären, was unter Entschei- 
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düng im Zusammenhang mit der zu erbringenden Unterstützung zu ver- 
stehen ist, und welche konzeptionellen Ansätze hieraus resultieren. Entschei- 
dungsimterstützung läßt sich klassifizieren im Sinner einer 



Bereitstellung von Informationen im Rahmen eines spezifischen Ent- 
scheidungskontextes 

- Bereitstellung von Modellen xmd Methoden mit dem 2äel, hiermit eine 
rationale Auswahl zu treffen aus einer Menge bestehender Alternativen 

- Bereitstellung von Werkzeugen, die einen Modellierungsprozeß im 
Rahmen eines individuellen Entscheidungskontextes ermöglichen. 



Die Bereitstellimg von Informationen bezieht sich auf den Bereich der infor- 
mationsverarbeitenden Disziplinen wie Informationsmanagement, Daten- 
banken bzw. auf die speziellen Methoden und Werkzeuge der Informatik, die 
zur Informationsverarbeitung bereitgestellt werden, so z.B. zur Entwicklung 
eines unternehmensweiten Datenmodells. 




Modellierung 

I 

Modell 

I 

Lösung 



Entschei dungs- 
prozeß 



Abb. 5: Problemsituation eines Entscheidungsträgers 
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Mit Modellen und Methoden zur Generierung relevanter Lösungen befassen 
sich die Disziplinen Operations-Research, Management Science und System- 
analyse. Entsprechend sind auch Expertensysteme hier einzugruppieren. Mit 
ihrer offenen Struktur und den methodischen Ansätzen sind sie jedoch im 
Grenzbereich zu den Modellierungswerkzeugen anzusiedeln. 



Mit der Auswahl eines Modells kann der Entscheidungsprozeß faktisch als ab- 
geschlossen betrachtet werden, da er sich in diesem Modell abbildet. Bei dem 
nachfolgenden Einsatz des Modells (z.B. eines Operations-Research-Modells 
oder eines Expertensystems) ist der Entscheidimgsprozeß bereits kanalisiert, da 
die Lösungen nur auf der Basis des in dem Modell eingelagerten Wissens 
erzeugt werden können. Dem Lösungsfindungsprozeß muß somit eine aktive 
Entscheidungsunterstützung mit dem Ziel einer Unterstützung des Model- 
lierungsprozesses vorangehen. Um Modelle entwickeln zu können, die dem 
individuellen Entscheidungskontext des Entscheidungsträgers entsprechen, 
sind Werkzeuge und Modellierungshilfen anzubieten. 



Mit diesen Modellierungshilfen wird der Handlungsspielraum des Entschei- 
dungsträgers erweitert, da er individuelle Modelle entwickeln kann und nicht 
mehr darauf angewiesen ist, auf vorgefertigte (und somit normative) Modelle 
und Lösungsmethoden zurückzugreifen. Insbesondere bei Entscheidungspro- 
blemen auf strategischer Ebene kann gezielt Unterstützvmg gegeben werden, 
da die Struktur des Problems nicht a priori bekannt ist, sondern sich erst 
während des Entscheidungsprozesses herauskristallisiert, d.h. die Gestaltung 
des Entscheidungsproblems hat evolutionären Charakter. Die Modellierungs- 
hilfen und -Werkzeuge müssen daher in einfacher Weise handhabbar sein, so 
daß der Entscheidungsträger diese Strukturierungs- bzw. Restrukturierungs- 
prozesse aktiv gestalten kann. Damit sind das Anwendungsfeld, die Hilfs- 
mittel und die Anforderungen an Decision-Support-Systeme skizziert: Nicht- 
bzw. semi-strukturierte Entscheidungsprozesse (Aspekt "Decision") sind mit 
Daten und Modellen (Aspekt "Support") durch informationstechnische Hilfs- 
mittel (Aspekt "System") aktiv zu unterstützen. Dabei gilt insbesondere zu 
prüfen, welchen Stellenwert die Modelle des Operations Research bzw. Ex- 
pertensysteme in einem Decision-Support-System haben, bzw. wie sie hier zu 
integrieren sind. 
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E. Decision Support Systeme 



Die Formen der Entscheidungsunterstützung weisen auf die Disziplinen hin, 
die den Begriff "Decision-Support-System (DSS)” charakterisieren. Bezogen 
auf einen realen Kontext eines Entscheidimgsträgers zeichnen sich diese Dis- 
ziplinen durch unterschiedliche Abstraktions- bzw. Formalisienmgsgrade aus, 
die sich in einem Schichtenmodell ausdrücken lassen. Decision Science bildet 
die Basisschicht eines Decision-Support-Systems. Die informationstechnische 
Komponente beinhaltet die Disziplinen Information Systems, Data Bases, 
Man-Machine-Commimication. Modelle imd Methoden zur Lösungsfindung 
werden durch die Disziplinen Management Science, Operations Research, 
Artifical Intelligence bzw. Expert Systems bereitgestellt. Die oberste Schicht 
bildet das sog. End-User-Computing. 




Klassifiziert man das Schichtenmodell nach den Komponenten "Decision", 
"Support" und "System", so sind die Disziplinen Information Systems und 
Management Science in dem Grenzbereich von "Decision" und "Support" 
anzusiedeln, während die Disziplinen Man-Machine-Communication und 
Artifical Intelligence bzw. Expertensysteme mit ihrer interaktiven Benutzer- 
orientierung zu dem Bereich "System" tendieren. In der ideal-typischen Form 
eines Decision-Support-Systems sind informations- und modelltechnische 
"Supporf-Komponenten integriert und werden im "End-User-Computing" 
dem Entscheidungsträger zur Modellierung bereitgestellt. Diese Integration 
setzt die gleichgewichtige Implementation der Komponenten "Dialog, Daten 
und Modelle" voraus. 
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Die Unterstützung des Benutzers in der Modellierungsphase durch ein End- 
User-Computing bedingt eine leistungsfähige Dialog-Komponente. Auf der 
Grimdlage einer adäquaten Kommunikationsebene sind mit einer interak- 
tiven Oberfläche die Interaktionen zwischen Benutzer und System zu ermög- 
lichen, wobei sowohl der Benutzer als auch das System aktiv am Modellie- 
rimgsprozeß teilnehmen. Dieser interaktive Kommunikationsprozeß bein- 
haltet somit eine Benutzer-Aktivität und eine System-Aktivität und stellt 
somit - gegenüber der interaktiven Oberfläche konventioneller Programm- 
systeme - eine echte Erweiterung des Gestaltungsspielraumes des Benutzers 
dar. Der Benutzer beteiligt sich aktiv am Modellierungsprozeß, indem er sein 
Wissen sowie Fakten und Daten der individuellen Entscheidungssituation in 
das System einbringt. Er skizziert damit die gegebene Problemsituation und 
projektiert den Ablauf des Entscheidungsprozesses nach subjektiven Krite- 
rien. 




Abb. 7: Komponentenstruktur eines Decision-Support-Systems 



Das System beteiligt sich aktiv am Modellierungsprozeß, indem es auf der 
Grundlage der subjektiven Kriterien dem Benutzer ein Funktionalitätsange- 
bot (z.B. Operations-Research-Modelle, Algorithmen) vmterbreitet. Mit diesem 
interaktiven Modellierimgsprozeß kann der Benutzer die "weißen Flecken" 
seiner Entscheidungssituation gestalten lernen, indem er die Relevanz der 
Angebote des Systems auf seine individuelle Entscheidungssituation hin 
überprüft, und er möglicherweise seine Vorgaben präzisiert bzw. neu formu- 
liert. Dies setzt einfache Modellbildungsbausteine voraus, damit der Benutzer 
zu einer gegebenen Entscheidungssituation das Modell in einfacher Weise 
entwerfen bzw. restrukturieren kann. Der Modellierungsprozeß hat somit 
evolutionären Charakter. 
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Mit dem Anspruch, im Dialog dem Benutzer Modelle und Daten zugänglich 
zu machen, unterscheiden sich Decision-Support-Systeme von klassischen 
Management Information Systemen (MIS), denn hierbei beschränkt sich der 
Dialog lediglich auf Abfragen: Auf der Grundlage einer Datenbank (DB) und 
eines zugehörigen Datenverwaltungssystems (DBMS: Data Base Management 
System) können mit Hilfe einer sog. Abfragesprache bzw. eines sog. Report- 
Generators lediglich Daten erzeugt und in gewünschter Form (z.B. als Grafik) 
dargestellt werden. 



Aus der Sicht der Funktionalität ist ein Decision-Support-System durch die 
Komponenten "Language System (LS), Knowledge System (KS) und Problem 
Processing System (PPS)" geprägt. Aus dieser Orientienmg heraus weist es auf 
strukturelle Ähnlichkeiten mit einem Expertensystem hin. 




Abb. 8: Funktionsstruktur eines Decision-Support-Systems 



Mit dem Language System wird die Kommunikationsebene zwischen Be- 
nutzer und Decision-Support-System definiert, indem die syntaktischen und 
semantischen Regeln fesfgelegt werden. Damit wird dargelegt, welche Art von 
Problemen behandelt werden können, und nach welchen Regeln die Kom- 
munikation zu erfolgen hat. Je nach Problemstellung kann in prozeduraler 
oder lücht-prozeduraler Form bzw. in entsprechender Mischform spezifiziert 
werden. 
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Mit dem Knowledge System wird der Anwendungsbereich des Decision-Sup- 
port-Systems festgelegt, indem die Daten, Modelle, Regeln und Aussagen ein- 
gelagert werden, die zur Bearbeitung eines Problems relevant sind. Hierbei 
können zur Darstellung des Wissens Datenbanken unterschiedlicher logischer 
Strukturen, Modell-Banken sowie Instrumente der Künstlichen Intelligenz 
wie z.B. Prädikatenkalküle und Produktionsregeln sowie deren Mischformen 
eingelagert sein. Das Knowledge System ist somit charakerisiert durch das 
Wissen sowie die Art der Darstellung und der Organisation des Wissens. 

Die dynamische Komponente des Decision-Support-Systems ist im Problem 
Processing System implementiert, das überwiegend durch die Techniken der 
Künstlichen Intelligenz gesteuert wird. Dieses System übernimmt die Infor- 
mationsgewinnung, indem es über das Language System vom Benutzer die 
Problembeschreibung und über das Knowledge System entscheidungsimter- 
stützenden Wissenselemente anfordert. Neben dieser Dialogfunktion ist die 
zentrale Aufgabe des Problem Processing Systems, aus der Problemdarstellung 
des Benutzers die gestaltenden Elemente des Problems zu erkennen, hieraus 
Strukturen zu entwickeln und möglicherweie ausführbare Prozeduren zu 
generieren. Da es sowohl die Informationen des BCnowledge Systems als auch 
die des Language Systems aufnehmen muß, ist es von den Strukturen dieser 
Systeme abhängig. Mit dieser Fähigkeit, die Probleme zu erkennen und dem 
Benutzer Strukturierungsvorschläge zu unterbreiten, werden dem Benutzer 
Gestalttmgssmöglichkeiten angeboten, die sich sowohl bei der Unterstützung 
der Modellierung als auch bei der Analyse der modellierten Entscheidungs- 
situation ausdrücken. Decision-Support-Systeme sind somit eine echte Er- 
weiterung gegenüber Expertensystemen. 



F. Operations-Research-Modelle und Expertensysteme als 
integrative Basiselemente von Decision-Support-Systemen 



In der derzeitigen Praxis werden Operations-Research-Modelle tmd Experten- 
systeme als Solver für wohlstrukturierte Probleme eingesetzt. Dabei zeigt sich, 
daß die praxisbezogene Relevanz dieser "stand-alone"-Modelle bei komplexen 
Entscheidimgssituationen zunehmend fragwürdiger wird. Mit dieser Einsicht, 
Entscheidimgsunterstützung nicht im eingeschränkten Sinne einer Auswahl 
von Alternativen aus einer wohldefinierten Menge sondern als einen evolu- 
tionären und individuell gestaltbaren Prozeß zu betrachten, sind gnmdsätz- 
lich veränderte Anforderungen an Funktionalität imd Leistungsumfang ent- 
scheidimgsunterstützender Systeme verbunden. Zudem gewinnt mit der ver- 
änderten Auffassung, Modelle als Ressourcen zu betrachten, der Modellie- 
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rungsprozeß zunehmend an Bedeutung. Mit dieser Neuorientierung, die sich 
als Erweiterung des Gestaltungspielraumes des Entscheidungsträgers darstellt, 
ist auch eine veränderte Sichtweise des Benutzers verbunden. Er wandelt sich 
von einem passiven Anwender eines Systems hin zu einem aktiven Gestal- 
ter, der aus seinem individuellen Entscheidungskontext heraus die entschei- 
dungsunterstützenden Systeme als Arbeitsumgebung betrachtet. In diesem 
Zusammenhang ist zu prüfen, wie sich Operations-Research-Modelle und Ex- 
pertensysteme in diese Philosophie integrieren lassen. 



Mit der Wandlung von der Unterstützung von Entscheidungsproblemen hin 
zu einer Unterstützung von Entscheidungsprozessen verändert sich auch die 
Orientierung der entscheidungsunterstützenden Systeme, d.h. von den "Pro- 
blemlöser-Systemen", als methoden-orientierte Systeme, ist der Übergang zu 
vollziehen zu einer interaktiven Modellierumgebung durch benutzer-orien- 
tierte Systeme. Hierbei sind Problemloser mit einer interaktiven Oberfläche 
nicht als benutzer-orientiert einzustufen, da sie nicht den Modellierungs- 
prozeß unterstützen sondern lediglich die Eingabe- und Ausgabefunktionen 
sowie den Formalisierungsprozeß benutzerfrevmdlich gestalten. Entsprechend 
ist die Interviewkomponente eines Expertensystems einzustufen, da sie ledig- 
lich dem Benutzer hilft, aus einer Gesamtheit von möglichen Alternativen 
die zu einem aktuellen Entscheidungsproblem zutreffende Lösung herauszu- 
filtern. 



In der Verwendimg als Problemlöser (Solver) verfügen Expertensysteme und 
Operations-Research-Modelle über umfangreiche Instrumentarien und aus- 
gereifte Techniken, um wohlstrukturierte Probleme lösen zu können. Diesem 
Leistungsmerkmal steht jedoch eine nur geringe Hexibilität gegenüber, da sich 
Solver auf individuelle oder veränderte Problemsituationen kaum bzw. nur 
mit hohem Aufwand anpassen lassen. Um den inkrementellen Prozeß der 
Strukturierung bzw. Restrukturierung einer Entscheidungssituationen unter- 
stützen zu können, erweist es sich daher als notwendig, in der Architektur 
eines Decision-Support-Systems Systemkomponenten vorzusehen, die fähig 
sind, dynamisch auf individuelle, unstrukturierte Entscheidungssituationen 
des Benutzers zu reagieren und aus der Situationsbeschreibung des Benutzers 
Modellkonzeptionen zu entwerfen, die in Modelle mit formalen Strukturen 
umzusetzen sind. Diese Komponenten haben somit Transferfunktionen 
wahrzunehmen, indem sie die Sichtweise des Benutzers in die des Systems 
übertragen und umgekehrt, d.h. sie müssen fähig sein, aus der deskriptiven 
Beschreibung des Benutzers Strukturen für adäquate Modellkonzeptionen zu 
entwickeln, um hieraus dem Benutzer individuelle Modelle imd Lösungen 
anzubieten. Es bietet sich an, individuelle Modellkonzeptionen auf der Basis 
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anwendungsspezifischer Operations-Research-Modelle und Expertensysteme 
zu erarbeiten, indem diese Problemloser bei der Modellierung als spezifizierte 
Komponenten zur Verfügung gestellt werden. Eine notwendige Voraus- 
setzung zur Realisierung dieser Transferfunktion ist eine entsprechende 
Kommunikationsebene. 




Transferkomponente des DSS 



V / 



Abb. 9: Transferfunktion eines Decision-Support-Systems 



Zur Unterstützxmg der Benutzeraktivität sind Modellierimgsprimitiva und 
Modellierimgshilfen (z.B. graphische, objektorientierte Oberflächen; Text- 
verarbeitungssysteme) anzubieten, die es dem Benutzer in einfacher Weise 
ermöglichen, die Problembeschreibung rechnervmterstützt zu skizzieren. Da- 
bei erweist sich der Einsatz graphischer, visueller Gestaltimgselemente als 
vorteilhaft, insbesondere wenn sie inhaltlich angereichert sind wie z.B. 
graphische Sjonbole für Transportmittel wie Kran, Förderband, LKW. 



Auf die Benutzeraktivität antwortet das System mit Vorschlägen zur Gestal- 
tung der Entscheidungssituation, indem es Modelle, Modellkomponenten 
bzw. Problem-Strukturierungen unterbreitet und diese erklärt bzw. analysiert. 



Mit den Anfordenmgen zur Gestaltung einer echten Interaktivität zwischen 
Benutzer und System sind bereits die Grundkomponenten der Architektur 
eines benutzer-orientierten Decision-Support-Systems skizziert. Die Kernele- 
mente bilden ein Modellierungs-Expertensystem, das Transferfunktionen 
zwischen Benutzer und System wahrnimmt, sowie eine Modell- und Metho- 
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denbank, die anwendungsspezifische Expertensysteme, Operations-Research- 
Modelle, Statistikpakete und Simulationsmodelle sowie Methoden und Ver- 
fahren enthält. 
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Abb. 10: Basis-Architektur eines "intelligenten" Decision-Support-Systems 



Das Modellierungs-Expertensystem unterstützt durch Transferfunktionen den 
Benutzer während des Modellierungsprozesses, insbesondere bei der Formali- 
siervmg der Aufgabenstellung, sowie bei der Analyse der Entscheidungssitua- 
tion. Es muß sich somit der Entscheidungssituation des Benutzers anpassen 
können und fähig sein, aus der eingelagerten Wissensbasis (Daten, Modelle, 
Prozeduren, Regeln) dem Benutzer Modellierungsvorschläge und Lösungen 
zu generieren. Hierzu muß es aus der Beschreibung des Benutzers formale 
Rahmenbedingungen und Strukturen bzw. Auswahlkritereien für Modell- 
komponenten entwickeln, mit dem Ziel, geeignete Modelle oder Modell- 
komponenten aus der Wissensbasis herauszufiltern und dem Benutzer im 
gesamten Entscheidungskontext als Lösungsvorschlag zu unterbreiten. 
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Hierbei ist die Modell-Konsistenz zu überprüfen, wobei die vom Benutzer 
gesetzten "Bounds" zu berücksichtigen sind. Bei funktionalen, strukturellen 
Abhängigkeiten zwischen einzelnen Modellkomponeneten sind die System- 
zustände jeweils zu aktualisieren. 



Zur Unterstützung dieser Funktionen sind dem Modellierungs-Experten- 
system Software-Werkzeuge und Werkzeuge der Künstlichen Intelligenz be- 
reitzustellen, so Z.B. Software-Bausteine (prozedurale, nicht-prozedurale) und 
Grundtechniken der Wissenspräsentation. Um eine geeignete Kommunika- 
tionsebene anbieten zu können, muß über entsprechende Language Systeme 
verfügt werden können. 

Um den Benutzer in der ersten Phase des Modellierungsprozeses an die Ent- 
wicklung von Modell-Strukturen heranzuführen, sind Strukturierungshilfen 
bereitzustellen, so z.B. Modellierungsbausteine wie Graphen, Matrizen, Infe- 
renzen, mathematische Terme, Grxmdtechniken der Statistik. Diese Hilfen zur 
Strukturierung einer Entscheidungssituation sind mit entsprechenden Erklä- 
rungen über Gesetzmäßigkeiten und Verwendungsmöglichkeiten zu ver- 
sehen. Dabei können charakteristische Anwendungs- bzw. Strukturierungs- 
beispiele hilfreich sein, um Analogien bilden zu können. 



Die für ein Decision-Support-System erforderliche Datenkomponente ist im- 
plizit durch den Zugriff auf das umliegende Informationssystem gegeben. 
Dieser Zugriff gewährleistet u.a. die Verfügbarkeit über den aktuellen Daten- 
bestand (betrieblicher und technischer Daten) und integriert das Decision- 
Support-System in das bestehende Untemehmensmodell. 



Die Modell- und Verfahrenskomponente bildet die Basis des Decision-Sup- 
port-Systems. Sie enthält Expertensysteme, Operations-Research-Modelle und 
Verfahren für die unterschiedlichsten Anwendungsfelder. Aus dieser Modell- 
und Methodendatenbank können die verschiedenen Elemente (Modelle, Mo- 
dellkomponenten, komplizierte Algorithmen) ausgewählt und dem Benutzer 
angeboten werden, der sie dann nach Überprüfung auf ihre Relevanz zur 
bestehenden Entscheidungssituation akzeptieren, verwerfen oder modifi- 
zieren kann. Dabei erscheint es sinnvoll zu prüfen, inwieweit im individu- 
ellen Modell des Benutzers Expertensysteme und Operations-Research-Mo- 
delle miteinander kombiniert werden können, indem geeignete Operations- 
Research-Modelle, Modellkomponeneten oder Verfahren als Bausteine in 
Expertensysteme integriert werden tmd umgekehrt. Operations-Research-Mo- 
delle und Expertensysteme können sich hierbei fallweise durch die in ihrem 
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Modellansatz jeweils inhärenten Vorteile ergänzen und somit eine Basis 
bilden für hochkomplexe, interdisziplinäre Modelle. 

Die Modell- und Verfahrenskomponente sowie die Datenkomponente bilden 
die Wissensbasis des Modellierungs-Expertensystems. 



G. Au^lick 



Operations-Research-Modelle zeichnen sich durch feste Modellstrukturen 
und die darauf basierenden effizienten Algorithmen aus. Sie setzen damit 
eine wohldefinierte Arbeitsumgebung des Entscheidimgsträgers und somit 
auch der Problemstruktur voraus, die i.a. nicht gegeben ist. Expertensysteme 
hingegen verfügen durch ihre offene Struktur und nicht-prozeduralen Ansatz 
über benutzer-orientierte Potentiale und sind somit insbesondere für (zu- 
nächst) diffuse, unstrukturierte Anwendungen geeignet. Aus diesen Über- 
legungen heraus, erweist es sich als konsequent und sinnvoll, die Fähigkeit 
eines Expertensystems (Wissen zur Lösung von Problemen einzusetzen) nicht 
nur in der Form eines Solvers zu nutzen, sondern sie auch für benutzer- 
orientierte Systeme verfügbar zu machen, so daß diese Systeme fähig sind, bei 
der Entwicklung von Modellen "intelligent" zu interagieren. Damit werden 
höherwertige Funktionen eröffnet, denn Entscheidungsunterstützung erfolgt 
nicht mehr im eingeschränkten Sinne einer Auswahl alternativer Lösungen 
mit Hilfe eines vorgegebenen Modells, sondern in der Form einer aktiven 
Unterstützimg des Entscheidungsträgers bei der eigentlichen Modellbildung. 
Mit dieser Systemaktivität wird eine echte Interaktivität zwischen Benutzer 
und System ermöglicht, denn das System leistet einen aktiven Beitrag zur 
Entscheidungsfindung. Voraussetzungen hierzu sind eine geeignete Kom- 
munikationebene zwischen Benutzer und System, die durch ein entsprechend 
koitzipiertes Modellierungs-Expertensystem bereitgestellt werden kann, imd 
eine Modell- und Methodenbank, in der das Wissen zur Entwicklung von 
Modellen abgelegt ist, d.h. das Modellierungs-Expertensystem muß mit seiner 
Wissensbasis verfügen köimen über 



- Operations-Research-Modelle mit ihren effizienten Algorithmen und 

- Anwendungs-Expertensysteme mit ihren Lösungsstrategien. 



Bei dem inkrementellen Prozeß der (interaktiven) Modellierung ist es dann 
naheliegend, zur individuellen Spezifikation des Benutzermodells die unter- 
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schiedlichen Philosophien der verfügbaren Basis-Modelle und -Methoden 
(Operations-Research-Modelle, Anwendungs-Expertensystenae, Algorithmen, 
Lösungsstrategien) bedarfsweise zu nutzen und darüberhinaus im Detail zu 
prüfen, ob und inwieweit ein Operations-Research-Modell mit seinen fixen 
Strukturen oder ein Expertensystem mit seinen offenen Strukturen jeweils als 
Komponenten in das Benutzer-Modell integriert werden können. Hierbei gilt 
als (grobe) Orientierurig, daß die Fähigkeit eines Expertensystems (auf der 
Grundlage eines nicht-prozeduralen Ansatzes Wissen zur Lösung von Pro- 
blemen einzusetzen) ihre Grenzen erreicht, wenn 



- das Entscheidungsproblem soweit aufbereitet ist, daß sich aus Effektivi- 
tätsgründen ein Wechsel zu den "harten" Modellen und Verfahren des 
Operations-Research anbietet, 

- durch die offene Struktur des Expertensystems bedingt (und dies insbe- 
sondere bei hochkomplexen Problemen) keine bzw. nur schwach abge- 
sicherte Aussagen über die Lösungsqualität möglich sind. Auch hier gilt 
zu prüfen, ob und inwieweit die "harten" Modelle und Verfahren des 
Operations-Research eingesetzt werden können, um die Lösimgsqualität 
zu verbessern. 



Operations-Research-Modelle und Expertensysteme bieten sich daher (ins- 
besondere in dieser gegenseitigen Ergänzung) als "Wissensmodule" von 
"intelligenten" Decision-Support-Systemen an, die den Entscheidungsträger 
ciktiv bei der Modellierung imterstützen. 



Mit diesen Ansätzen können die Anforderungen aufgenommen werden, die 
von einem "intelligenten" System zur Entscheidungsunterstützung zu 
erfüllen sind: 



- Das System muß dem Benutzer eine einfache Benutzeroberfläche an- 
bieten, damit der Prozeß der Strukturierung bzw. Restrukturienmg der 
Entscheidimgssituation ohne umfangreiches bzw. detailliertes System- 
wissen erfolgen kann. 

- Dem Benutzer sind einfache Werkzeuge anzubieten mit deren Hilfe er 
seine Entscheidungssituation erfassen und individuell darstellen kann. 



Diese Forderungen nach einer einfachen Benutzeroberfläche und einfachen 
Modellierungs-Werkzeugen sind nicht nur aus methodischer Sicht zur Ge- 
staltimg des Modellierungsprozesses begründet. Mit der wachsenden Kom- 
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plexität der zu entwickelnden Modelle geht eine verstärkte Akademisierung 
der Modell-Entwickler einher, die aus volkswirtschaftlicher Sicht nicht ver- 
tretbar erscheint, denn der höhere Bedarf an Akademikern und die damit 
verbundenen Aus- und Weiterbildungsmaßnahmen gehen zu Lasten der 
minder-qualifizierten sog. Praktiker und Klein- und Mittelbetriebe sind lang- 
fristig von dieser Akademisierimg ausgeschlossen. Damit verschärfen sich die 
Forderungen nach der Einfachheit, um den unterschiedlichen beruflichen 
Qualifikationsstufen adäquate Instrumente und Werkzeuge anbieten zu 
können. 



- Das System entwickelt bei hoher Flexibilität Vorschläge zur Gestaltung 
der Entscheidungssituation, indem es dem Benutzer "Wissensmodule" 
zur Strukturierung seiner Problemsituation anbietet, d.h. es zwingt den 
Entscheidungsträger nicht, seine individuelle Entscheidungssituation 
fixen, vorgeformten Modellstrukturen anzupassen. 

Das System eröffnet dem Benutzer Möglichkeiten, die selbstentwickelten 
Modelle zu analysieren und auf ihre Relevanz zur bestehenden Ent- 
scheidimgssituation hin zu überprüfen. 



Mit diesen Eigenschaften kann der Benutzer mit dem System in einer echten 
Interaktivität rückgekoppeltes Lernen betreiben. Sie sind daher ein gnmd- 
legendes Maß zur Bewertung "intelligenter" entscheidungsunterstützender 
Systeme. 
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Optimierung von Datenfemübertragungsnetzen 
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Von-Melle-Park 5; D-2000 Hamburg 

Zusammenfassung: Der Betrieb eines privaten Datenfemübertragungsnetzes erfordert die An- 
mietung von Standleitungen der Deutschen TELEKOM. Um einen wirtschaftlichen Netzbetrieb 
zu ermöglichen, besteht für den Netzanbieter die Aufgabe, eine kostenminimale Netztopologie 
unter Berücksichtigung der Mietleitungsgebühren zu bestimmen. Auf der Grundlage eines ge- 
mischt-ganzzahligen Optimierungsmodells der Linearen Programmierung wird ein Verfahren 
zur Lösung dieser Aufgabe angegeben. Außerdem wird das Problem eines fehlertoleranten 
Netzes diskutiert. Am Beispiel einer Aufgabenstellung aus der Praxis wird die Qualität des 
vorgeschlagenen Lösungsansatzes dargestellt und bewertet. 

Summary: The establishment of a private wide area network requires the rental of point-to- 
point-lines from the German TELEKOM. In Order to opjerate such a network economically it is 
necessary to find a topology of minimal cost. Based on a mixed-integer LP-model an approach 
for the Solution of this problem is proposed. In addition the Situation of a fault tolerant net- 
work with respect to topology is discussed. Referring to an example from practice the quality 
of the given approach will be demonstrated and evaluated. 

1. Aufgabenstellung 

Aufbau und Betrieb eines privaten Datenfemübertragungsnetzes (WAN = Wide Area Net- 
work) sind in der BR Deutschland nur möglich, wenn der Betreiber die für sein Netz erforder- 
lichen Kommunikationswege Leitungsverbindungen von der staatlich autorisierten Gesell- 
schaft TELEKOM anmietet. Diese Leitungsverbindungen werden mit Hilfe von gemieteten 
Standleitungen hergestellt, die eine Punkt-zu-Punkt-Verbindung ermöglichen. In den Leitungs- 
endpunkten befinden sich i.d.R. Netzknoten-Rechner des Betreibers, die den Zugang der Be- 
nutzer zu dem privaten Netz eröffnen. Der Betreiber kann auf diese Weise seine Netzdienste 
einer breiten Öffentlichkeit anbieten, wobei sein Netz so dimensioniert sein muß, daß die ge- 
forderten Datenübertragungsleistungen erfüllt werden können. 

Wichtige Voraussetzung für den wirtschaftlichen Betrieb eines privaten WAN ist zunächst die 
Minimiemng der Mietkosten für Standleitungen der TELEKOM. Dabei sind nicht nur die 
Übertragungskapazität und die Gebühren einer Leitung zu berücksichtigen. Von entscheiden- 
dem Einfluß ist vielmehr die Topologie des Netzes, wobei mit möglichst wenigen und kosten- 
günstigen Leitungen das geforderte Kommunikationsdatenvolumen bewältigt werden soll. Ge- 
sucht werden daher die kostenminimalen Leitungsverbindungen bei einer gegebenen 
regionalen Verteilung der Knotenpunkte im Netz. Die Lage der Netzknoten ergibt sich aus der 
regionalen Nachfrage der Kunden des Netzbetriebs. Dabei wird vorausgesetzt, daß der Netz- 
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betreiber die geographische Lage der Netzknoten vorgibt. Als Freiheitsgrad zur Gestaltung der 
Netztopologie verbleibt die Leitungsführung zwischen den Knoten. 

Diese Leitungsführung kann mit einfachen oder vielfachen Leitungen der gleichen Übertra- 
gungskapazität von beispielsweise 64 kBit/sec gestaltet werden. Bei hohem Kommunikations- 
aufkommen können auch mehrere Leitungen der Kapazität 2 MBit/sec angemietet werden. 

Die Auswahl der Leitungsverbindung muß in der Weise erfolgen, daß die Anforderungen der 
Netzbenutzer im Hinblick auf die Input- bzw. Output-Datenmengen erfüllt werden. Dabei 
kann ein Kommunikationsweg auf direktem Weg zwischen zwei Knoten gewählt werden. Es 
sind aber auch Kommunikationswege über drei oder vier Knoten zulässig. Mehr als zwei Um- 
wegknoten (Transitknoten) je Übertragungsweg sind nicht erlaubt, weil dann die Schaltzeiten 
in den Rechnern der Netzknoten eine technisch nicht tolerierbare Verzögerung in der Signal- 
übermittlung bewirken würden. 

Somit sind jene Standleitungen unter der Zielsetzung einer kostenminimalen Gesamtgebühr 
auszuwählen, die das geforderte Kommunikationsvolumen über 0 bzw. 1 oder 2 Transitknoten 
transportieren können. 

Untersuchungen zu allgemeinen Fragen der technischen Auslegung von WAN liegen vor, vgl. 
/!/ und /2/ sowie die dort angegebenen Literaturhinweise. Die spezielle Fragestellung eines 
privaten Netzbetreibers wird unter dem Aspekt der exakten Optimierung jedoch nicht beant- 
wortet. Im folgenden soll daher ein Verfahren zur Bestimmung der Netztopologie unter der 
Zielsetzung der minimalen Netzgebühren entwickelt werden. 

2. Definitionen 

In Abb. 1 ist ein Netz mit 6 vorgegebenen Knoten dargestellt. Zwischen den Knoten sind 
insgesamt 7 Leitungen vorgesehen. Hinsichtlich der Kommunikationswege wird zwischen 
Strecken und Routen unterschieden. 

Eine Strecke gibt die direkte Verbindung zwischen zwei Knoten an. Sie entspricht einer oder 
mehreren Standleitungen, deren Mietkosten das Zielkriterium der Minimierung bestimmen. 

Eine Route bestimmt den Kommunikationsweg zwischen zwei Knoten im Netz. Entsprechend 
den technischen Randbedingungen der Datenübertragung werden Routen mit 0, 1 oder 2 
Transitknoten zugelassen. Eine Route ohne Transitknoten entspricht somit einer Strecke. 

Unter Berücksichtigung dieser Festlegung entspricht die Verbindung von Knoten 1 nach Kno- 
ten 3 einer Route mit einem Transitknoten (Nr. 2). Die Verbindung von 2 nach 5 kann über die 
Strecke 2-5 erfolgen oder durch eine Route mit den Transitknoten 3 und 4 hergestellt werden. 
Beide Varianten gelten als zulässige Lösung für eine Kommunikationsverbindung zwischen 
den Knoten 2 und 5. 

In allen Knoten des Netzes können Datenströme eingespeist oder abgezogen werden. Das In- 
put- und Output-Datenvolumen muß derart durch das Netz geschleust werden, daß die je- 
weils auf den Strecken anfallende Übertragungslast in beiden Richtungen die Leitungskapazi- 
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tät nicht übersteigt. Dabei sind die Überlagerungen der Belastung über alle Routen, die diese 
Strecke benutzen, zu erfassen und in der Kapazitätsrestriktion zu berücksichtigen. 

Das Zielkriterium der Minimierungsaufgabe ergibt sich aus der Summe der Mietkosten aller in 
der gesuchten Netztopologie erforderlichen Leitungen. Der Rechnung werden die monatlichen 
Kosten der Miete für Standleitungen zugrunde gelegt. Dementsprechend wird für die externen 
Kommunikationsanforderungen das prognostizierbare Maximum der Benutzeraktivitäten wäh- 
rend eines Monats in Ansatz gebracht. Diese Prognose kann sich auf vorhandene Messungen 
stützen; daneben können auch die im Netzbetrieb vertraglich vereinbarten maximalen Kom- 
munikationsvolumina als Richtwert herangezogen werden. 
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3. Formulierung des mathematischen Modells 

Für die Kennzeichnung der Variablen und Parameter des mathematischen Ansatzes wird die 
folgende Indexmenge benutzt: 

i, j, k, 1 € {l,2,...imax} Bezeichnung der Netzknoten; k, 1 bezeichnen Transitknoten. 
Außerdem gilt: i < j ; k, 1 i,j. 

Die Variablen des Modells sind vom Typ kontinuierlich bzw. ganzzahlig. Mit den kontinuierli- 
chen Veränderlichen wird die Übertragungslast auf den möglichen Routen im Netz bezeichnet. 
Dabei werden Routen mit bis zu 2 Transitknoten betrachtet. Die ganzzahligen Variablen be- 
zeichnen die Leitungskapazitäten für 64- kBit-und 2-MBit-Leitungen; dabei können eine oder 
mehrere Leitungen der gleichen Kapazität gemeinsam geschaltet werden. Da die Kosten von 9 
Leitungen mit 64-kBit-Kapazität das Kostenniveau einer 2-MBit-Leitung erreichen, kann der 
Wertebereich dieser ganzzahligen Variablen entsprechend eingeschränkt werden. 

Im einzelnen gilt: 



Xij 


[kBit/sec] 


Übertragungslast der Route von i nach j 


Xijk 


[kBit/sec] 


Übertragungslast der Route ij über Transitknoten k 


Xijkl 


[kBit/sec] 


Übertragungslast der Route ij über die Transitknoten k, 1 


Uij 


H 


ganzzahlig; Anzahl von 64-kBit-Leitungen 


Vij 


[-] 


ganzzahlig; Anzahl von 2 MBit-Leitungen 


Die Parameter des Modells bezeichnen einerseits die monatlichen Leitungskosten, den Kom- 
munikationsbedarf von den Knoten i nach j im Netz und schließlich die genannten Übertra- 
gungskapazitäten der beiden Leitungstypen; andererseits sind als Parameter die Leitungsko- 
sten als monatliche Mietgebühren für eine 64-kBit-Leitung bzw. eine 2-MBit-Leitung 
vorgesehen. 


Im einzelnen gilt: 




dij 


[kBit/sec] 


Kommunikationsbedarf von i nach j 


CI 


[kBit/sec] 


Kapazität einer 64 kBit-Leitung 


C2 


[kBit/sec] 


Kapazität einer 2 MBit-Leitung 


klij 


[DM/Monat] 


Kosten einer 64 kBit-Leitung 


k2ij 


[DM/Monat] 


Kosten einer 2 MBit-Leitung 
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Das Modell der gemischt-ganzzahligen linearen Optimierung hat folgende Gestalt: 
Zielfunktion: 

^ (kiij Uij+k2ij vip => Minimum 
*</ 

Nebenbedingungen: 

- Erfüllung des Kommunikationsbedarfs 

Xij + ^ ; für alle i,j. 

k ü 

- Einhaltung der Leitungskapazitäten 

Xij + ^ clUij + QVij ; für alle ij. 

k ü 

- Begrenzung der Variablen 

Xij, Xijk, Xijkl > 0. 

0< uij< 9, ganzzahlig. 

Die mögliche Anzahl der 64-kBit-Leitungen kann beispielsweise auf 9 beschränkt werden, weil 
die Gebühren für 10 und mehr Leitungen ungünstiger sind als die Kosten einer 2-MBit-Lei- 
tung. 

Wegen der Bedingung i < j ergibt sich für die Indexmenge {ij) eine Mächtigkeit entsprechend 
0.5 imax (imax-1); d.h. für ein Netz mit 6 Knoten sind insgesamt 15 Leitungsverbindungen zu 
betrachten. Unter Berücksichtigung der Transitknoten gilt für die Indexmengen (ijk) die 
Mächtigkeit 0.5 imax (max-1) (imax-2) bzw. für (ijkl) die Mächtigkeit 0.5 imax (imax-1) 
(imax-2) (imax-3). 

Dementsprechend ergeben sich für ein Netz mit 6 Knoten insgesamt 30 ganzzahlige Variable 
und 255 kontinuierliche Variable. Dabei sind 2 * 15 entsprechend 30 Nebenbedingungen zu 
berücksichtigen. Diese Betrachtungen zeigen, daß das mathematische Modell bei größerer Kno- 
tenanzahl sehr große Dimensionen annimmt. Die numerische Bewältigung großer Modelle 
stößt an praktikable Grenzen, wenn die Anzahl der Variablen über einhunderttausend und die 
Zahl der Nebenbedingungen über dreißigtausend steigt. Somit können mit diesem Modell 
Netze mit bis zu 20 Konten berechnet werden. Mit Hilfe von vereinfachenden Annahmen über 
die Topologie des Netzes und über die Freiheitsgrade der Netzstruktur lassen sich erheblich 
größere Netze mit vertretbarem Aufwand evaluieren. Derartige Vereinfachungen können sich 
ergeben, wenn z.B. Kommunikationsverbindungen über Transitknoten eingeschränkt werden. 
Eine andere Möglichkeit besteht darin, die Anzahl der theoretisch möglichen Leitungswege 
derart zu reduzieren, daß nur jene Routen in dem Modell berücksichtigt werden, die sich 
innerhalb einer vorgegebenen Kostenbegrenzung befinden. 
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Schließlich muß aber davon ausgegangen werden, daß Netze mit mehr als 20 Knotenpunkten 
in der Praxis der kommerziellen Netzanbieter gegenwärtig nicht bekannt sind. Daher dürften 
sich die häufiger auftretenden Optimierungsprobleme auf Netze mit vergleichsweise geringer 
Knotenanzahl konzentrieren. In diesen Fällen läßt sich der beschriebene Ansatz unter Verwen- 
dung der vorhandenen Rechenprogramme zur mathematischen Optimierung einsetzen. 

4. Anforderungen an ein ausfallsicheres Netz 

Eine optimale Topologie, die auf der Grundlage des beschriebenen LP-Modells berechnet wird, 
zeichnet sich im allgemeinen durch eine sternförmige Struktur der Leitungsverbindungen aus 
(vgl. Abb. 2). Die an den Knoten angegeben Prozentzahlen stellen die Auslastung der Lei- 
tungs-Kapazität zu beiden Richtungen dar. Damit läßt sich offensichtlich zeigen, daß bei dem 
Ausfall einer Leitungsverbindung mit großer Wahrscheinlichkeit mindestens ein Knoten im 
Netz nicht mehr erreicht wird. Dies bedeutet, daß das Netz nicht als ausfallsicher gelten kann. 
Ein kommerzieller Netzanbieter hat jedoch das Ziel, seinen Kunden ein möglichst ausfallsiche- 
res Netz anzubieten. Daher sollte die Topologie des Netzes so gestaltet sein, daß alle Knoten 
des Netzes noch mit der geforderten Kommunikationsleistung erreichbar sind. Die Garantie 
der Ausfallsicherheit des Netzes bei Unterbrechung einer Leitungsverbindung ist daher eine 
Forderung, die in das Optimierungsmodell aufgenommen werden muß. D.h. jeder Knoten im 
Netz muß mit Hilfe von Umwegverbindungen zusätzlich erreichbar sein, wobei die Übertra- 




Abb.2 
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gungskapazitäten der Umwegleitungen das zusätzliche Kommunikationsvolumen aufnehmen 
müssen. 



Dementsprechend sind Kapazitätsreserven in den vorgesehenen Leitungen vorzusehen. Das 
mathematische Modell ist daher so zu formulieren, daß zunächst jeder Knoten durch minde- 
stens eine Umwegverbindung erreichbar ist. Dies erfordert mindestens zwei Leitungsverbin- 
dungen pro Knoten. Allein mit dieser zuusätzlichen Nebenbedingung ergeben sich Topolo- 
gien, die im Gegensatz zur Sternstruktur eine Ringstruktur aufweisen. Allerdings reicht diese 
zusätzliche mathematische Bedingung nicht aus, weil damit die Erfüllung des gesamten Kom- 
munikationsvolumens nicht garantiert werden kann. 

Eine geschlosene Lösung dieser Aufgabe, ein ausfallsicheres Netz kostenoptimal zu planen, 
läßt sich ebenfalls mit Hilfe eines LP-Modells erreichen (vgl. Abb. 3). Dabei werden sämtliche 
Umwegverbindungen mit Hilfe zusätzlicher Variablen im Modell derart berücksichtigt, daß 
die dafür erforderlichen Reservekapazitäten vorgehalten werden. Die Erfassung der Reserve- 
kapazitäten muß systematisch für alle Knoten Verbindungen {ij} angegeben werden. D.h., im 
Modell müssen alle Situationen, die sich bei Unterbrechung einer beliebigen Knotendirektver- 
bindung ergeben, simultan berücksichtigt werden. Dadurch wird die Zahl der kontinuierlichen 
Variablen erheblich gesteigert, während sich die Anzahl der ganzzahligen Variablen nicht er- 
höht. Daneben wird aber noch die Anzahl der Nebenbedingungen erhöht, weil für jede Lei- 
tungsverbindung eine Ersatzverbindung unter der Bedingung eines Ausfalls des direkten 
Übertragungsweges formuliert werden muß. 




Abb. 3 






34 



Die Modelldimensionen erreichen in diesem Fall des sicheren Netzes einen solchen Umfang, 
daß höchstens Netze mit bis zu 10 Knoten mit vertretbarem Aufwand berechnet werden kön- 
nen. Daher ist es naheliegend, hier ein kombiniertes Verfahren aus einem mathematisch exak- 
ten Modell und einem heuristischen Modifizierungsansatz zu entwickeln. Dabei kann als Aus- 
gangssituation für die Heuristik zunächst die optimale Topologie des nicht ausfallsicheren 
Netzes gewählt werden. Mit Hilfe heuristischer Regeln werden sodann zusätzliche Leitungs- 
verbindungen hinzugefügt, wobei für jede Knotenverbindung (Strecke) geprüft wird, ob das 
Übertragungsvolumen durch Umwegrouten zusätzlich erfüllt werden kann. 

Das heuristische Verfahren geht dabei von Erfahrungsregeln aus, die mit Hilfe des exakten 
Modells für ausfallsichere Netze gewonnen wurden. Als besonders wirkungsvoll haben sich 
dabei Ringverbindungen über jeweils drei Knoten erwiesen. In Abhängigkeit von dem Bere- 
chungsaufwand, der noch in Kauf genommen werden soll, können darüber hinaus Ringverbin- 
dungen über 4 bzw. 5 Knoten in die Planung einbezogen werden. Außerdem können Knoten 
mit großem Übertragungsbedarf bei der Leitungsführung bevorzugt werden. Eine heuristische 
Lösung ist in Abb. 4 für das bereits dargestellte 6-Knotennetz wiedergegeben. 



heuristisch hinzuge- 
fügte Leitungen 




Abb. 4 
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Das Kostenoptimum des nicht ausfallsicheren Netzes gibt die untere Kostengrenze für eine 
Topologie an. Die Kosten der ausfallsicheren Topologie erhöhen sich im Vergleich zu dieser 
Untergrenze erfahrungsgemäß um etwa 50 %. Eine Erhöhung der Kosten um 100 % bedeutet 
eine gleichzeitige Verdoppelung aller Leitungen des nicht ausfallsicheren Netzes. Da bei einer 
Verdoppelung aller Leitungen ebenfalls ein sicheres Netz entsteht, bildet der zweifache Ko- 
stenbetrag des nicht ausfallsicheren Netzes die Obergrenze einer sicheren Netztopologie. Zur 
Abschätzung der Güte des heuristischen Verfahrens kann daher das beschriebene Kosteninter- 
vall zwischen 175 % und 200 % der optimalen Top>ologie des nicht ausfallsicheren Netzes 
herangezogen werden. 

Zur Vermeidung des "Single-Point-Effekts" muß jeder Knoten mindestens über zwei verschie- 
dene Strecken erreichbar sein. Damit soll erreicht werden, daß bei Ausfall einer vorgelagerten 
Strecke ein Knoten im Netz nicht isoliert wird und damit nicht mehr von allen anderen Kno- 
ten erreichbar ist, obwohl die unmittelbar in seiner Nähe bestehenden Leitungen funktionsfä- 
hig sind. In diesem Zusammenhang wird das oben dargestellte LP-Modell durch eine zusätzli- 
che Bedingung erweitert, wobei sichergestellt ist, daß jeder Knoten durch mindestens zwei 
verschiedene Strecken mit dem Netz verbunden ist. Die damit optimierte Topologie kann als 
Ausgangslösung für die heuristische Verbesserung verwendet werden. 

5. Praktischer Einsatz des Verfahrens 

Die praktische Anwendung eines Verfahrens der mathematischen Optimierung in Verbindung 
mit einer heuristischen Methode erfordert im Interesse des Benutzers eine weitgehende Auto- 
matisierung des Planungsprozesses (vgl. Abb. 5). In diesem Zusammenhang wurde ein Pla- 
nungssystem entwickelt, das aus einer Kopplung zwischen graphikfähigem Arbeitsplatzrech- 

Datenflussdlagramm des Netzoptimierungssystems 




Ergebnisdarstellung 




Schnittstelle zum Arbeitsplatzrechner 









Abb. 5 
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ner und einer Großrechenanlage besteht. Die Großanlage dient vor allem der Durchführung 
des Optimierungsprozesses; hierfür wird das kommerziell verfügbare LP-System MPSX /3/ 
und ein Modellgenerator für das mathematische Modell eingesetzt. Der Arbeitsplatzrechner 
dient vor allem der graphischen Darstellung der Planungsergebnisse, wobei der Benutzer die 
Netztopologie in einer geographischen Karte betrachten kann. In Abb. 6 ist beispielhaft eine 
derartige Bildschirmanzeige dargestellt. Der Benutzer hat die Möglichkeit, interaktiv mit Hilfe 
von Cursor- und Mausbedienung die technischen Daten einer Strecke oder eines Knotens zu 
hinterfragen. Zugleich kann er einen Vergleich zwischen der bestehenden Topologie des Istzu- 
stands und einer neu geplanten Struktur anstellen. Auf diese Weise kann interaktiv die Frage 
eines möglichen Netzausbaus oder einer Änderung der Netztopologie analysiert werden. 





Abb. 6 



Abschließend sollen am Beispiel eines Netzes mit 6 Knoten die Kostenverbesserungen im Ver- 
gleich zu einer manuell ermittelten Topologie dargestellt werden. Die dieser Problemstellung 
zugrunde liegenden Daten sind näherungsweise einem Fall der Praxis entnommen. 



Lösungsansatz 


mtl. Kosten 


Einsparung 


Manuelle Lösung ausfallsicher 


82.000,- DM 


» Bezugsgröße 


optimierte Lösung nicht ausfailsicher 


48.000,- DM 


+ 41 % 


Obergrenze der Kosten 


96.000,- DM 


- 17% 


optimierte Lösung ausfallsicher 


72.000,- DM 


+ 12 % 


heuristische Lösung 


78.000,- DM 


+ 5% 



Tabelle 1: kostenmäßige Auswirkung der Lösungsansätze 
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Die optimale Lösung der nicht ausfallsicheren Topologie ist in der oben bereits dargestellten 
Abb. 2 wiedergegeben. Dieses optimierte ausfallsichere Netz ergibt sich aus Abb. 3, während 
die heuristische Lösung für eine ausfallsichere Topologie bereits in Abb. 4 dargestellt wurde. 
Einen Überblick über den Aufwand an Rechenleistung vermittelt Abb. 7. 
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Abb. 7 



Anzahl 

Strukturvar. 



Dieses Beispiel zeigt den Einsatz des LP-Verfahrens als Optimierungsmethode, wobei aller- 
dings bei größerer Komplexität des Netzes auf ein exaktes Lösungsverfahren verzichtet wer- 
den muß. Die Kombination aus Optimierungsansatz und anschließender heuristischer Modifi- 
kation der Lösung im Hinblick auf Ausfallsicherheit des Netzes liefert Ergebnisse, die auch bei 
einem Verzicht auf Optimalität wesentliche Kosteneinsparungen gegenüber einer manuellen 
Planung ergeben. 
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ren Optimierung, Hersteller dieses Systems ist IBM. 




Last Verteilung in einem Klienten- Server-Modell 
als teamtheoretisches Problem 

Josef Matulka 

Abteilung für Angewandte Informatik 

Institut für Informationsverarbeitung und Informationswirtschaft 
Wirtschaftsuniversität Wien 
Augasse 2-6 
A-1090 Wien 



1 Motivation 

Die EDV-Landschaft der meisten Organisationen ist heute geprägt durch ein buntes Neben- 
einander von Computern verschiedenster Hersteller und Leistungsklassen, die zumeist durch 
ein lokales Netzwerk miteinander verbunden sind. 

Die Gesamtrechenkapazität, die in diesem Netz verteilt zur Verfügung steht, ist dabei oft 
größer als die Kapazität traditioneller Großrechner. Im Gegensatz zu den Mainframes, bei 
denen erprobte und wohldurchdachte Mehrbenutzerbetriebssysteme für die effiziente Auftei- 
lung der vorhandenen Ressourcen auf die einzelnen Benutzer sorgen, ist bei diesen vernetzten 
Systemen jedoch häufig zu beobachten, daß jeder Anwender nur die Rechenleistung seines 
lokalen Arbeitsplatzrechners in Anspruch nimmt. Lastet dieser eine Benutzer seinen Rechner 
nur zu einem geringen Teil aus oder ist er überhaupt abwesend, dann liegt die Rechenka- 
pazität teilweise oder zur Gänze brach, obwohl prinzipiell die Möglichkeit bestünde, sie zur 
Erfüllung von Aufgaben anderer Benutzer heranzuziehen. 

La^tverteilungsalgorithmen sollen durch eine automatische Aufteilung der Arbeitslast auf 
die zur Verfügung stehenden Rechner eine effizientere Nutzung eines vernetzten Systems 
ermöglichen. Mit der Zahl der durch Netzwerke verbundenen Rechner ist auch die Literatur 
gewachsen, die sich mit der Frage der Last Verteilung beschäftigt. 

Ein Teil der Arbeiten [4] [13] [6] konzentriert sich darauf, die Frage zu lösen, wie eine fixe 
Anzahl von Aufgaben {tasks) optimal auf eine gegebene Menge von Rechnern verteilt werden 
soll. Es wird dabei unterstellt, daß die Kosten für jede beliebige derartige Allokation bekannt 
sind und daß jene Zuordnung zu finden ist, die die minimalen Kosten verursacht. Es ist also 
eine Variante des im Operations Researdi wohlbekannten Zuordnungsproblems zu lösen {task 
allocation problem). Diese Modelherung hat den Vorzug einer klar definierten Lösung, die 
man verwenden kann, um allfällige Heuristiken auf ihre Brauchbarkeit hin zu untersuchen. 
Problematisch sind jedoch die sehr starken Annahmen, die notwendig sind, um zum Resultat 
zu kommen. Insbesondere die Frage, wie denn die Kostenfunktionen zu erhalten sind, wird 
kaum diskutiert: 

We assume interference costs are derived somehow from user specifications, Com- 
piler analyses, and dynamic monitoring of the task force; and that a common unit 
of measure can be found for execution, communication, and interference costs. 

[13, S. 1390] 
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Eine andere Gruppe von Aufsätzen [5] [11] [16] bemüht sich weniger um das Auffinden op- 
timaler Lösungen, als um realistischere Modellbildungen. Das vernetzte System und seine 
Arbeitslast wird dabei mit den Methoden der Warteschlangentheorie modeUiert. Die Zielset- 
zung ist hier nicht die Minimierung einer abstrakten Kostengröße, sondern das Finden von 
brauchbaren Heuristiken, die angeben, welche Aufgaben lokal von dem Computer behandelt 
werden sollen, an dem sie generiert wurden und welche an andere Computer weitergegeben 
werden sollen. Das Ziel besteht im Erzielen von Verbesserungen bei Leistungsmetriken wie 
Antwortzeit oder Durchsatz durch einen Las tausgleich zwischen den Rechnern {load balan- 
cing Problem). Die Arbeitslast besteht dabei nicht aus einer fix vorgegebenen Anzahl von 
Aufgaben, sondern es wird angenommen, daß an allen Rechnern laufend neue Aufgaben ge- 
neriert werden. Die Verwendung von Warteschlangenmodellen ist insofern von Vorteil, als 
diese für Leistungsanalysen von Computersystemen standardmäßig verwendet werden und 
auf meßbaren Größen aufbauen. Eine explizite Berücksichtigung der Heterogenität von Auf- 
gaben und Rechnern ist durch die Verwendung von Waxteschlangennetzwerken sehr einfach 
möglich [7]. 

Der Vorzug der ersten Gruppe von Arbeiten liegt in der klaren Definition eines Optimie- 
rungsproblems, während letztere sich durch höhere Realitätsnähe auszeichnet. Ziel der hier 
vorliegenden Arbeit ist es, die Vorzüge beider Ansätze zu verbinden, indem aus einem War- 
teschlangenmodell Kostenfunktionen abgeleitet werden, die die Formulierung eines Minimie- 
rungsproblems erlauben, für das ein verteilter, teamtheoretisch orientierter Lösungsalgorith- 
mus angegeben wird. Da in gegenwärtig existierenden, praktischen Systemen nahezu alle 
verteilten Applikationen vom Klienten- Server Typ sind, wird die Arbeitslast in dieser Form 
modelliert. 

Der folgende zweite Abschnitt führt näher aus, was unter Klienten-Server-Applikationen in 
einem vernetzten System verstanden werden soll. Der dritte Abschnitt beschreibt, wie aus 
einem meßbaren Arbeitslastprofil Kostenfunktionen gewonnen werden können. Der vierte 
Abschnitt bringt die Ableitung des Optimierungsalgorithmus. Im letzten Abschnitt erfolgt 
schließlich eine zusammenfassende Bewertung und ein Ausblick auf weitere notwendige Ar- 
beiten. 



2 Klienten-Server-Applikationen in vernetzten Syste- 
men 

Unter einem vernetzten System verstehen wir n Rechner, die durch ein Netzwerk derart mit- 
einander verbunden sind, daß jeder Rechner mit jedem Rechner kommunizieren kann. Jeder 
dieser Rechner wird dabei durch ein separ ables Warteschlangennetzwerk [12] modelHert. 
Wir werden in weiterer Folge annehmen, daß es sich dabei um ein offenes Warteschlan- 
gennetzwerk, das aus den drei Einheiten CPU, Platte und Netzwerkinterface besteht (siehe 
Abbildung 1), handelt. Alle Formeln werden für diesen Spezialfall angegeben, Erweiterungen 
für eine beliebige, rechnerabhängige Anzahl von Einheiten sind jedoch ohne Schwierigkeiten 
möglich. 

Um trotz Verwendung desselben Modells für alle Rechner eine gewisse Heterogenität der 
Rechner modelHeren zu können, gehen wir davon aus, daß die Einheiten bei unterschiedlichen 
Rechnern unterschiedlich leistungsfähig sind. Die Leistungsfähigkeit jedes Rechners j wird 
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Abbildung 1: Wartschlangenmodell eines Computersystems 



dabei durch ein Tripel von ProportionalitätsfaJktoren bestimmt: 

RECHNER,- = , (1) 

die das Leistungsverhältnis zu einem definierten Standardredmer ausdrücken. gibt 

an, um welchen FaJctor die CPU des Rechners j langsamer ist, als die des Standardrechners, 
ßDiSK ßNETio definieren dasselbe für Platten- und Netzwerkzugriffe. Ein Faktor, der 
kleiner als 1 ist, bedeutet also immer, daß die jeweihge Einheit (CPU, Platte, Netzwerkin- 
terface) schneller ist als die entsprechende Einheit des Standardrechners. 

Auf diese n Rechner sind insgesamt m Serverprozesse optimal zu verteilen. Diese verur- 
sachen die Hauptaxbeitslast des Systems. Es könnte sich dabei z. B. um Datenbankserver 
handeln. Für jeden dieser Server gibt es außerdem Klientenprozesse, die vergleichsweise 
wenig Rechnerleistung benötigen und jeweils einem Rechner fix zugeordnet sind. Durch 
diese Klientenprozesse wird der Arbeitsaufwand modelHert, der durch das Zusammenstellen 
von Anfragen an die Serverprozesse und — nach erfolgter Antwort — durch die geeignete 
Präsentation und Formatierung der Ergebnisse generiert wird. Konzeptionell gibt es auf je- 
dem Rechner m Klientenprozesse, einen für jeden Server, von denen jedoch manche inalctiv 
sein können. Dies wird dann der Fall sein, wenn von diesem Rechner aus keine Anfragen an 
den betreffenden Server gestellt werden. 

Neben der Arbeitslast, die durdi diese Server- und Klientenprozesse verursacht wird, ent- 
steht auch noch durch die Kommunikation über das Netzwerk, die notwendig wird, wenn 
Server und Klient sich nicht am selben Rechner befinden, eine gewisse Arbeitslast, die durch 
Serviceanforderungen an die Einheiten der beiden kommunizierenden Rechner (insbesondere 
wohl CPU und Netzwerkinterface) modelhert wird. Kollisionen bei der Übertragung wer- 
den nicht berücksichtigt, was bei leicht belasteten Netzwerken vertretbar erscheint. Frühere 
Arbeiten [2] [15] haben ja auf den dominierenden Einfluß der CPU-Belastung und die ver- 
gleichsweise geringe Auswirkung des Netzwerkverkehrs auf die Übertragungsdauer hingewie- 
sen. 

Ein wichtiges Anwendungsgebiet für dieses Modell liegt in der optimalen Konfiguration von 
Transaktionssystemen, die bei steigender Tendenz heute ca. 25 % des Computermarktes 
ausmachen [1]. 
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3 Vom Arbeitslastprofil zu Kostengrößen 

In diesem Abschnitt wird gezeigt, wie aus Arbeitslastmetriken, also aus Größen, die durch 
Monitorprogramme erhoben werden können, mit Hilfe eines einfachen Leistungsmodells Lei- 
stungsmetriken berechnet werden können. Durch Kombination dieser Metriken wird dann 
eine Kostenfunktion definiert, die es erlaubt, eine Optimierungsaufgabe zu formulieren. Diese 
mehrstufige Vorgangs weise ist in Abbildung 2 dargestellt. 



Arbeitslastmetriken 




+ 

Kostenmetriken 



Abbildung 2: Mehrstufige Ableitung 



3 . 1 Arb eit slas t met r iken 

Wie bereits erwähnt, berücksichtigt unser Modell explizit die Klienten-Server-Organisation 
der gegenwärtig verfügbaren verteilten AppHkationen. Die Arbeitslastcharakterisierung um- 
faßt daher drei Komponenten: Serverprozesse, Klientenprozesse und die Kommunikation 
zwischen den beiden. 

Die Serviceanforderungen, die der Server i an den Standardrechner richtet, um eine Anfrage 
zu beantworten, wird durch das Tripel SERVER, beschrieben 

SERVER, = (sf sf ^netio>^ z = 1, . . . , m (2) 

Dabei bezeichnet die Serviceanforderung, die an die CPU des Rechners gericlitet wird 
und jene, die sich an die Platteneinheit richtet, bezeichnet an sich die Ser- 

viceanforderung an das Netzwerkinterface; da aber angenommen wird, daß jeder Server für 
die Beantwortung von Anfragen nur lokale Ressourcen in Anspruch nimmt, ist immer 

Null und wird nur einer geschlosseneren Notation wegen definiert. 

Analog beschreibt das Tripel CLIENT, 

CLIENT,- = df d™) i = 1, . . . , m (3) 

die Serviceanforderungen, die durcli die jeweihgen Klientenprozesse verursacht werden. Auch 
hier gilt, aus den gleichen Gründen wie zuvor, = 0. 

Die Kommunikation zwischen Server- und Klientenprozessen wird durch das Tripel COMM,* 
COMM, = (ef ef i = 1, . . . , m (4) 
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modelliert. Es wird davon ausgegangen, daß durch die Abwicklimg einer Anfrage die durch 
das Tripel COMM,- spezifizierten Serviceanforderungen auf beiden Rechnern, dem Rechner, 
von dem die Anfrage ausgeht, und dem Rechner, auf dem sich der Serverprozeß befindet, ent- 
stehen, wenn diese beiden Rechner nicht identisch sind. Da Nachrichtenübertragung primär 
die CPU und das Netzwerkinterface beanspruchen, wird man i. a. davon ausgehen können, 
daß ef = 0 ist. Falls Server- und Klientenprozeß sich am selben Rechner befinden, ent- 
stehen annahmegemäß keine Serviceanforderungen durch Kommunikation (die Kosten für 
lokale Kommunikation werden vernachläßigt). 



Es ist zu beachten, daß in allen drei Tripeln die Arbeitslast als Serviceanforderung an den 
Standardrechner spezifiziert wurde. Will man diese in Anforderungen an einen konkreten 
Rechner j transformieren, so muß man mit den entsprechenden Proportionalitätsfaktoren 
oder multiplizieren. 

Um die Arbeitslastbeschreibung für ein offenes Warteschlangennetzwerk [12] zu vervollstän- 
digen, benötigt man schließlich noch die Anforderungsraten, mit denen von einzelnen Rech- 
nern Anfragen an die diversen Server gerichtet werden. Zusätzlich zu den obigen Tripeln 
seien also auch die folgenden mittleren Ankunftsraten durch Messungen bekannt: 






i 

j 






(5) 



Dabei bezeichnet A,j die mittlere Rate, mit der von Benutzern des Rechners j Anfragen an 
den Server i gerichtet werden. 



Um später einfacher notieren zu können, definieren wir zusätzlich Gesamtankunftsraten für 
jeden Server i: 

n 

A,\ = ^ ^ A,j i = 1, . . . , 771 (6) 

i=i 



3 • 2 Leist ungsmo dell 

Mit Hilfe des in [12] angegebenen Algorithmus für die Auswertung von offenen Warteschlan- 
gennetzwerken, ist es möglich, mit den im vorherigen Unterabschnitt definierten Arbeitslast- 
metriken als Input, Leistungsgrößen für Jeden der Rechner zu berechnen, wenn man weiß, 
welche Server nun tatsächlich dem Rechner zugeordnet sind. 

Um eine solche Zuordnung von Servern auf Rechner formal beschreiben zu können, definieren 
wir für jeden Rechner j einen 77i-dimensionalen Vektor Uj mit der folgenden Interpretation: 

_ r 1 Server i ist dem Rechner j zugeordnet > . 

\ 0 Server i ist nicht dem Rechner j zugeordnet ' ' 

wobei Uij die i-te Komponente des Vektors bezeichnet. 

Wir können damit in Abhängigkeit von einer bestimmten Serverzuordnung Uj für jeden 
Rechner j bestimmen, welche Serviceanforderungen an den einzelnen Einheiten b = CPU, 
DISK, NETIO entstehen. 

Die Serviceanforderungen, die durch den Klientenprozeß i pro Anfrage an das Servicezentrum 
b des Rechners j gerichtet werden, sind (unabhängig von der Serverzuordnung Uj) gegeben 
durch: 

j^cLJENT,b J ^ CPU, DISK, NETIO (8) 
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Dtircli den Serverprozeß i kommt es am Servicezentrum b nur daoin zu Serviceanfordenmgen, 
wenn sich dieser Server am Rechner j befindet {uij = 1): 

^SERVER, b ^ ßb^b^,, j ^ CPU, DISK, NETIO (9) 

Durch Kommunikation zwischen Server- und Klientenprozeß kann es schließlich in zwei ge- 
trennten Fällen zu Serviceanforderungen kommen: Wenn» der Server i sich nicht am Rechner 
j befindet, entstehen für jede von j an den Server i gerichtete Anfrage Serviceanforderungen 
^jjCOMMcitenty Befindet sich der Server i hingegen am Rechner j, so entstehen durch die 
Beantwortung aller nicht-lokalen Anfragen ebenfalls Serviceanforderungen (^D^OMMservcry 

jjCOMMclUnt,b ^ (10) 

jjCOMM..rver,b ^ ßb^b^,, 

Die Gesamtserviceanforderung, die durch eine Anfrage an den Server i am Rechner j entsteht, 
berechnet sich dann als: 

j^b jjCLIENTfb j^SERVER^b jjCOMMcUent,b j^COMMserver^b (12) 



3 • 3 Leist ungsmet r iken 

Durch einfache Multiplikation mit den entsprechenden Ankunftsraten kann man aus den 
im vorherigen Unterabschnitt berechneten Serviceanforderungen die Auslastungen Ufj der 
einzelnen Einheiten b = CPU, DISK, NETIO des Rechners j durch Anfragen an den Server 
i bestimmen. Sie bereclinen sich als Summen der im folgenden definierten vier Größen: 



rrCLIENT,b _ 


nCLIENT,b ^ 


(13) 


rjSERVER,b _ 


jjSERVERJby 


(14) 


rjCOMMclientfb 

U^j — 


r\CO MM dient jb \ 
E'ij Aij 


(15) 


jjCOMMserver^b 




(16) 



Die Gesamt auslastung Uj für die Einheit 6 des Recliners j durch alle Server berechnet sich 
damit folgendermaßen: 

m 

^6 ^ ^ j^CLIENTyb ^SERV ER,b jj-COMMclient^b _j_ -^COMM Server ^b (1*^) 

i=l 

Zuordnungen Uj, die bei irgendeiner Einheit b zu Werten > 1 führen, werden wir als 
unzulässig^ alle anderen als zulässig bezeichnen. 

Für alle zulässigen Zuordnungen können wir nun auch die mittlere Antwortzeit für jede 
Applikation i an jeder Einheit b des Rechners j als Summe der folgenden vier Teilantwort- 
zeiten berechnen [12]: 



T)CLIENT,b 
r,CLIENT,b _ ^ij 

- i-u^ 



(18) 
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nSERVER,b 



Ä COMMdientfb 

ij 



nCOMMserver,b 



D 



SERVBRfi 



»J 



1-U^ 



D- 



^COMMdientJb 



l-U^j 

COMMserver,b 



D\ 



1-C/J 



(19) 

( 20 ) 
( 21 ) 



Für unzulässige Zuordnungen werden wir jeden dieser vier Summanden — tmd damit auch 
die Summe auf unendlich setzen: 

4 = 00 ( 22 ) 



Schließlich vereinbaren wir auch für die Summe dieser Antwortzeiten über alle Einheiten h 
des Rechners j eine Notation, die wir später in der Kostenfunktion verwenden werden: 



jfCLIENT 


__ ^ j^CLIENT,b 


(23) 


j^SERVER 


_ ^ j^SERVERJb 


(24) 


■nCOMMclient 


^ ^ ^COMMclientyb 

5 


(25) 


nCO MM Server 
% 


^ ^ j^CO MM Server, b 


(26) 



b 



3.4 Kostenmodell und Kostenmetriken 



Es wurde nunmehr gezeigt, wie man für jede Zuordnung uj für jeden Rechner und jeden 
Server Antwortzeitgrößen berechnen kann. Man kann diese Metriken nun in verschiedenster 
Weise zu Kostenfunktionen jj kombinieren. Wir werden die folgende wählen: 

7o(«,) = + 

+ Rff^'"^^Xi. + RfP'^'^’^'"^{Xi.-\ij) (27) 

m 

7i(«i) = X^7ij(w<i) (28) 

*=1 

Die Kosten jeder Applikation werden hier einfach als Summe der durch die Ankunftsraten 
gewichteten Antwortzeiten der einzelnen Applikationen definiert. 



4 Der Optimierungsalgorithmus 

Im vorhergehenden Abschnitt wurde unter Verwendung der Warteschlangentheorie ein Al- 
gorithmus angegeben, der es jedem Rechner j erlaubt, die Kosten jeder möglichen Server- 
zuordnung Uj zu bestimmen. In diesem Abschnitt wird ein Algorithmus angegeben, der die 
solchermaßen ermittelten Kostenfunktionen 7 ^- verwendet, um für jede geforderte Kombina- 
tion z von zu allozierenden Servern die optimalen Zuordnungen 



( 29 ) 
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für die einzelnen Rechner zu bestimmen, z ist dabei ein m-dimensionaler 0-1- Vektor, der 
angibt, welche der m Server überhaupt dem entsprechenden Netz zugeordnet werden sollen. 
Das üblicherweise betrachtete Problem, alle vorhandenen Server zu allozieren, ergibt sich als 
Spezialfall mit -sr = wobei Im den m-dimensionalen 1- Vektor bezeichnet. 

Da der Algorithmus Begriffe und Methoden der Teamtheorie verwendet, werden im er- 
sten Unterabschnitt zunächst jene teamtheoretischen Grundlagen eingeführt, die für das 
Verständnis des Algorithmus notwendig sind. Zwei weitere Unterabschnitte stellen dann den 
Zusammenhang zwischen diesen Begriffen und der ursprünglichen Serverzuordnungsaufgabe 
her bzw. bringen die Ableitung eines wichtigen Satzes, der die Korrektheit des im letzten 
Unterabschnitt dargestellten und anhand eines Beispiels erläuterten Algorithmus sicherstellt. 



4.1 Teamtheoretische Grundlagen 

Die Teamtheorie ist eine Variante der Entscheidungstheorie für mehrere Akteure, die ur- 
sprünglich von Marschak und Radner [14] entwickelt wurde. Spätere Weiterentwicklungen 
und Modifikationen erfolgten insbesondere durch Ho und Chu [9] [3] [10] [8] sowie durch 
Tenney und Sandell [18] [17]. 

Unter einem Team versteht man eine Menge von Akteuren (Entscheidungsträgern, Teamkol- 
legen), die in einer durch eine endliche Menge von möglichen Zuständen definierten Umwelt 
je eine Entscheidung treffen und dabei ein gemeinsames Ziel verfolgen. Jeder Akteur verfügt 
über eine individuelle Kostenfunktion^ die für alle zulässigen Entscheidungen einen Kosten- 
wert liefert. Welche Entscheidungen für einen bestimmten Akteur zulässig sind, hängt dabei 
vom Umweltzustand und von den Entscheidungen seiner Teamkollegen ab. Das Teampro- 
blem besteht nun darin, eine Punktion, die optimale Teamentscheidungsfunktion^ zu finden, 
die für jeden möglichen Zustand der Welt die optimale Entscheidung jedes einzelnen Ak- 
teurs spezifiziert, wobei diese optimale Teamentscheidung die Eigenschaft besitzt, daß sie die 
Teamkosten, das ist die Summe der Kosten aller Akteure, minimiert. Zugleich damit wird 
auch die optimale Teamkostenfunktion bestimmt; dabei handelt es sich um jene Punktion, 
die für jeden möglichen Zustand der Welt die minimalen Teamkosten angibt. 

Im folgenden werden wir nun eine sehr eingeschränkte Variante eines Teamproblems forma- 
lisieren, das sich - wie im nächsten Unterabschnitt gezeigt wird - in einfacher Weise auf 
das Serverzuordnungsproblem abbilden läßt. Wir führen für ein Team T von n Akteuren 
folgende Notation ein: 

• Z bezeichnet die Menge aller zulässigen Umweltzustände 2 r; wir werden immer davon 
ausgehen, daß es sich dabei um die Menge aller m-dimensionalen 0-1-Vektoren handelt. 

• bezeichnet die individuelle Kostenfunktion des Akteurs j, über die wir keinerlei 
Annahmen treffen. 

• Der m-dimensionale 0-1- Vektor uj bezeichnet die Entscheidung des j-ien Akteurs. 

• Eine Teamentscheidung u wird notiert als n-Tupel von Einzelentscheidungen: 



u = (ui,...,w„) 



(30) 
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wobei wir — wie auch bei allen später noch eingeführten Tupeln — alternativ auch 
die Notation 

^ = («i W 

verwenden werden. Bei gegebenem Umweltzustand z sind dabei nur jene Tupel zuläs- 
sige Entscheidungen, für die gilt: 

= ^ (32) 

JGT 

• Eine optimale Teamentscheidung u* werden wir durch einen Stern kennzeichnen: 

= (33) 

• Die optimale Teamentscheidungsfunktion a* ist ein Tupel von optimalen Entschei- 
dungsfunktionen der einzelnen Akteure: 

a* = (aj,...,«;). (34) 

Sie weist jedem Umweltzustand z £ Z die optimale Teamentscheidung u*, d. h. die 
Lösung der folgenden Minimierungsaufgabe, zu: 

Minimiere (35) 

jeT 

unter den Nebenbedingungen: (36) 

(1) E“i = ^ (37) 

jeT 

(2) u, G Z jeT (38) 

Da die Lösung dieser Optimierungsaufgabe i. a. nicht eindeutig sein wird, ist auch die 
optimale Teamentscheidungsfunktion nicht eindeutig definiert. 

• Die optimale Teamkostenfunktion schließlich wird mit 7 * bezeichnet. Sie weist jedem 
Umweltzustand z e Z die minimalen Teamkosten C* zu: 

C^’ = E7iK*) (39) 

jeT 

Im Gegensatz zur optimalen Teamentscheidungsfunktion ist diese Funktion eindeutig 
bestimmt. 

Im folgenden werden wir ein Teamproblem Tk immer durcli ein Tupel von individuellen 
Kostenfunktionen 7 ^ 

7 * = [7i.---,7n] (40) 

beschreiben und seine Lösung Tj^ als Tupel notieren, das aus der optimalen Teamkosten- 
funktion 7 ]J und der optimalen Teamentscheidungsfunktion aj besteht: 



'^k *“ bik) — (^iki» • • • J ^Ikn)] 



(41) 
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4.2 Zusammenhang mit dem Serverzuordnungsproblem 

Durch diese sehr spezielle Definition eines Teamproblems ergibt sich der Zusammenhang mit 
dem Serverzuordnungsproblem recht unmittelbar: 

• Den n Akteuren entsprechen die n Rechner des vernetzten Systems. 

• Der Umweltzustand z entspricht der Konfiguration der zu allozierenden Server. Er 
kann als Aufforderung an das Team, eine gewisse Menge von Servern optimal zu- 
zuweisen, verstanden werden. Die Menge Z entspricht der Menge aller denkbaren 
Zuordnungsaufforderungen. 

• Die Entscheidungsvariable Uj gibt die Serverzuordnung des Rechners j an. 

• Die Kostenfunktion 7^ entspricht der im vorhergehenden Abschnitt abgeleiteten Punk- 
tion. 

• Die Beschränkungen, durch die wir die Menge der zulässigen Entscheidungen im Team- 
problem eingeschränkt haben, wurden so gewählt, daß sie für das Serverzuordnungs- 
problem Sinn ergeben: 

“ Alle Uj G T müssen 0-1- Variablen sein, da es sich grundsätzlich um ein Zuord- 
nungsproblem handelt. 

“ Durch die Forderung, daß die Summe aller Entscheidungen immer z ergeben muß, 
wird sichergestellt, daß alle Server, deren Zuordnung durch z gefordert wird, genau 
einmal zugeordnet werden. 

Mit dieser Interpretation entspricht das Teamproblem exakt dem zu lösenden Serverzuord- 
nungsproblem. 

4.3 Dekomposition von Teamproblemen 

Um zu einem verteilten Lösungsalgorithmus zu gelangen, werden wir das oben definierte 
Teamproblem in Subprobleme aufspalten, diese lösen und durch Kombination von Sub- 
teamlösungen dann das ursprüngliche Problem lösen. Unter einem Subteamproblem eines 
Teamproblems Ta verstehen wir dabei ein Teamproblem Tß, dessen individuelle Kosten- 
funktionen alle auch individuelle Kostenfunktionen des Teamproblems Ta sind. Jene indi- 
viduellen Kostenfunktionen von die nicht auch Teil von Tß sind, werden wir in diesem 
Zusammenhang auch als Restkostenfunktionen bezeichnen. 

Es läßt sich nun beweisen, daß man, anstatt eiii gegebenes Teamproblem Ta zu lösen, folgende 
Vorgangsweise wählen kann: 

1. Man löst ein beliebiges Subteamproblem Tß- 

2. Man löst jenes Teamproblem Tc, dessen individuelle Kostenfunktionen all jene indivi- 
duellen Kostenfunktionen des ursprünglichen Teamproblems Ta sind, die nicht Teil des 
Subteamproblems Tß sind, plus die optimale Teamkostenfunktion 7^ des Subteampro- 
blems Tß. 
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Die optimalen Teamkostenfunktionen von und Tc sind dann identisch, und durch ge- 
eignete Hintereinanderausführung der optimalen Entscheidungsfunktionen von Tb und Tc 
lassen sich die optimalen Entscheidungsfunktionen von Ta konstruieren. Diese Dekomposi- 
tionsmöglichkeit wird im folgenden Satz formalisiert: 

Satz 1 (Dekomposition von Teamproblemen) 

Gegeben seien drei Teamprobleme Ta, Tb und Tc 



Ta = [ 71 . 72 , 73 ] (42) 

Tb = [ 71 , 72 ] (43) 

Tc = [ 73 , 74 ] (44) 

sowie deren jeweilige Lösungen T^, Tq und Tq 

'^A = blA ? ^A = {^Al > ^A 2 > ( 4 ^) 

Tb = [7ß,«ß = (aBi,«B2)] (46) 

Tc = [7c,«c = (öC3,«C4)] (47) 



W^enn die individuelle Kostenfunktion 74 des Teamproblems Tc so gewählt wird, daß sie 
gleich der optimalen Teamkostenfunktion 7^ des Teamproblems Tb ist 

74 = 7ß (48) 



dann sind die optimalen Teamkostenfunktionen der Teamprobleme Ta und Tc identisch und 
das Tupel T* 



mit 



r* = [7a,«* 


— (ai,Q!2,‘^C3)] 


(49) 


al{z) = 


‘^ßl(<^C4(^)) 


(50) 


al{z) = 


“B2(öC4(^)) 


(51) 



ist eine Lösung des Teamproblems Ta- 

Beweis: Die Gültigkeit des Satzes folgt aus dem Bellman’schen Optimalitätskriterium und 
ergibt sich durch entsprechendes Einsetzen der Definitionen der optimalen Teamentschei- 
dungs- und Kostenfunktionen in die beiden optimalen Teamkostenfunktionen. 

Es läßt sich ohne Schwierigkeiten zeigen, daß die Gültigkeit dieses Satzes nicht auf Fälle 
beschränkt ist, in denen das Subteamproblem aus nur zwei individuellen Kostenfunktionen 
besteht und nur eine Restkostenfunktion vorhanden ist, sondern für beliebige Partitionen 
der Menge der individuellen Kostenfunktionen eines Teamproblems. Da ein Subteampro- 
blem ebenfalls ein Teamproblem ist, läßt sich dieser Satz auch rekursiv anwenden, d. h. die 
Lösimg des Subteamproblems läßt sich durch neuerliche Anwendung des Satzes und damit 
neuerliche Aufspaltung berechnen, usw. Damit läßt sich ein Teamproblem durch Lösung 
einer Hierarchie von (einfacheren) Teamproblemen lösen, wa,s im Lösungsalgorithmus ver- 
wendet werden wird. 
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4.4 Der Koordinationsalgorithmus 

Als letzte Voraussetzung für den Lösungsalgorithmus definieren wir auf der Menge der Ak- 
teure (=Rediner) eine Koordinationshierarchie G und führen folgende Notation ein: Mit 
G'^{j) bezeichnen wir die Menge aller Söhne (Nachfolger) von j und mit G'~{j) bezeichnen 
wir die einelementige Menge bestehend aus dem Vaterknoten (Vorgänger) des Akteurs j. Aus 
dem Lösungsalgorithmus wird hervorgehen, daß jeder Akteur durch seinen jeweihgen Vater- 
knoten koordiniert wird. Durch diese Koordinationsstruktur G ergibt sich eine Klassifikation 
der Rechner in einfache Rechner (Blätter von G), einfache Koordinatoren (innere Knoten 
von G) und einen Chefkoordinator (Wurzel von G). Damit können wir nun folgenden Al- 
gorithmus angeben, der für jede beliebige Serverallokationsforderung zi die kostenminimale 
Aufteilung der Server auf die n Rechner liefert: 

Phase 0 (Berechnung der individuellen Kostenfunktionen) 

Jeder Akteur j berechnet seine individuelle Kostenfunktion jj nach dem im vorherge- 
henden Abschnitt beschriebenen Algorithmus. 

Phase 1 (Lösung der Teamprobleme) 

Jeder Akteur j wartet bis er von allen von ihm direkt koordinierten Rechnern k G G'^{j) 
deren optimale Teamkostenfunktionen 7J übermittelt bekommen hat, berechnet dann 
die Lösung Tf 

= [7;, = (ocjj, («;fc)*€G+(»)] m 

des Teamproblems Tj 

( 53 ) 

und gibt dann die solchermaßen bestimmte optimale Teamkostenfunktion 7^ an den 
ihn koordinierenden Akteur l G G~{j) weiter. 

Anmerkungen: Für einfache Rechner ist die optimale Teamkostenfunktion gleich der 
lokalen Kostenfunktion. Die optimale Teamkostenfunktion des Chefkoordinators ist 
die des gesamten Serverzuordnungsproblems. 

Phase 2 (Bestimmung der optimalen Zuordnungen) Jeder Akteur j erhalt vom ihn 
koordinierenden Akteur l G G~~{j) den Zuweisungsauftrag zj übermittelt und verwen- 
det die in Phase 1 bestimmte optimale Teamentscheidungsfunktion um daraus seine 
eigene optimale Entscheidung Uj sowie die Aufträge Zk für die von ihm koordinierten 
Rechner k G G^{j) abzuleiten: 

( 54 ) 

Zk = ocjkizj) A;eG+(j) (55) 

Anmerkungen: Der Zuweisungsauftrag z\ des Chefkoordinators ist als Teil der Pro- 
blemstellung gegeben, bei einfachen Rechnern j entspricht der Zuweisungsauftrag der 
optimalen Entscheidung. 

In Abbildung 3 sind die erforderlichen Berechnungen und Kommunikationsvorgänge sche- 
matisch dargestellt. Rechner 3 ist ein Koordinator, der die einfachen Rechner 4 und 5 
koordiniert. 
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5 Bewertung und Zukunftsperspektiven 

Wir haben durch Verbindung von Warteschlangennetzwerken und Teamtheorie ein Modell 
entwickelt, daß in der Lage ist, die optimale Serverplazierung in einem durch Klienten- 
Server- Applikationen geprägten vernetzten System zu bestimmen. Aus unserer Sicht weist 
das Modell folgende Vorzüge auf: 

Es berücksichtigt explizit die Heterogenität von Servern wie Rechnern. 

Kostenfunktionen werden nicht als gegeben angenommen, sondern es wird explizit 
gezeigt, wie sie aus an realen Systemen meßbaren Größen ableitbar sind. 

Es wird ein exaktes Optimum berechnet, das verwendet werden kann, um die Qualität 
von Heuristiken zu testen. 

Es handelt sich um einen verteilten Algorithmus, bei dem jeder Rechner nur seine eigene 
Warteschlangenrepräsentation kennen muß, nicht jedoch die aller anderen Rechner. 

Die Mehrstufigkeit des Algorithmus ermöglicht eine Arbeitsteiligkeit bei Weiterentwick- 
lungen. Der Koordinationsmechanismus ist völlig unabhängig vom darunterliegenden 
Warteschlangenmodell. 

Die Hauptnachteile des Modells liegen im — für Zuordnungsprobleme charakteristischen 
— großen Rechenaufwand, der das Optimieren von Systemen mit einer größeren Anzahl 
von Servern praktisch unmöglich macht, und in der Annahme von fixen Arbeitslastprofilen. 
Damit ergibt sich auch automatisch das Programm für weitere Arbeiten: 

• Durch Einführung von Heuristiken soll die Laufzeit des Algorithmus gesenkt werden. 
Insbesondere soll untersucht werden, welche Auswirkungen es auf die Leistungsfähig- 
keit des Algorithmus hat, wenn man einzelne Koordinatoren die Zuordnungskosten 
der von ihnen koordinierten Rechner auf der Grundlage eines vereinfachten System- 
modells schätzen läßt (vgl. Konzept der Abstraktion in [17]), anstatt ihnen die wahren 
Kostenfunktionen von diesen Rechnern übermitteln zu lassen. 

• Der Algorithmus soll um Mechanismen erweitert werden, die eine automatische Mi- 
gration von Servern bei wesentlichen Änderungen von Ankunftsraten oder bei Neu- 
einführung von Servern ermöglichen. 

• Die Wirkungsweise des gesamten Algorithmus und der vorgeschlagenen Erweiterungen 
soll schließlich durch Simulationsstudien unter unterscliiedhchen Szenarien überprüft 
werden. 

Eine Reformulierung dieses Algorithmus für verteilte objektorientierte Systeme ist einfach 
möglich und bereits im Entstehen. 
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Zusammenfassung 



Zukünftige Systeme des Multiprojektmanagements sollten die Projektleitung stärker mit Vorschlägen zur Ausregelung 
von Störungen im Projektablauf unterstützen, als dies bisher üblich ist. 

Störungen lassen sich bereits mit konventioneller Netzplantechnik-Software auffinden. Sie lassen sich zum Teil nach 
allgemeingültigen Regeln auflösen. Die bisherigen Erfahrungen bei der Entwicklung des Prototyps NETEX zeigen, daß 
sich die Projektleitungen weitgehender unterstützt fühlen, wenn auch inhaltliche Vorschläge aufbereitet werden. Diese 
Möglichkeiten bieten wissensbasierte Techniken. Insbesondere mit Expertensystemen kann das repetitive Verhalten der 
Projektleitungen bei der Ausregelung von Störungen auf einem Rechner abgebildet werden. Durch die Verbindung von 
Netzplantechnik mit wissensbasierten Techniken können mehrere Alternativen zur Störungsausregelung untersucht wer- 
den. 



1. Einleitung 

Fachexperten verfügen über ein reichhaltiges Angebot an Handlungsvarianten, um konkrete Problemstellungen zu lösen. 
In Abhängigkeit der gesetzten Ziele, der jeweiligen Situation und den Nebenbedingungen entscheiden sie sich nach ihrem 
Ermessen für die günstigste Handlimgsvariante. Die Erfahrung der Experten spiegelt sich darin wieder, daß sie auf viele 
Situationen und Bedingungen mit guten Entscheidungen reagieren können. Mit Hilfe der wissensbasierten Techniken, 
insbesondere der Expertensysteme, gelingt es, umfangreichere Teile des repetitiven Problemlösungsverhaltens von Fach- 
experten unter wesentlich geringerem Aufwand auf einem Computer abzubilden als dies mit konventioneller Software 
möglich ist. 

Probleme der realen Welt lassen sich zum Teil in mathematische Modelle transformieren und durch Operations Re- 
search (OR) Verfahren lösen. Bisweilen geht, aufgrund notwendiger Vereinfachungen, die exakte Repräsentation der 
Fragestellung des Anwenders verloren. Zu anderen Problemen existieren keine OR-Verfahren. Es kann Vorkommen, daß 
bestimmte Fragestellungen mittels OR grundsätzlich lösbar sind, die Erarbeitung der Lösung jedoch sehr rechenintensiv 
und mit vertretbarem Aufwand nicht zu bewältigen ist. Wissensbasierte Techniken versprechen Problemstellimgen zu lö- 
sen, die mit OR-Modellen nicht vernünftig darstellbar sind oder nur mit unvertretbar hohem Zeitaufwand gelöst werden 
können. Damit bietet sich die Gelegenheit, mit maschineller Unterstützung in neue Problemfelder vorzudringen. In Ver- 
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bindung mit OR-Algprithmen können die Anwender in klassischen OR-Bereichen umfassender als bisher durch Rechner 
unterstützt werden. 

An der Wissenschaftlichen Hochschule für Unternehmensführung in Koblenz (WHU) wird zur Zeit, in enger Zusam- 
menarbeit mit einem großen Dienstleistungsunternehmen, ein wissensbasiertes System zur Unterstützung des Multipro- 
jektmanagements entwickelt. Bisher hat sich die Netzplantechnik bei der Unterstützung einzelner Aufgaben der Projekt- 
leitung bewährt, beispielsweise der Planung und Kontrolle von Projekten. Das Netzplantechnik-Expertensvstem NETEX 
soll das Dienstleistungsuntemehmen bei der System-Projektleitung unterstützen, d.h. bei der Koordination von Pro- 
jektaufgaben, die im eigenen Unternehmen bearbeitet werden und denen, die an Fremdfirmen vergeben werden. Im 
Rahmen der Projekte werden Richtlinien und Vorschriften für die Einführung neuer Dienstleistungen in der Kommuni- 
kationstechnik entwickelt. Zur Zeit arbeiten daran mittelbar imd unmittelbar ca. 3000 Mitarbeiter in 1600 Projekten, wo- 
bei 600 Projekte eine Lauf^it von mehr als 3 Jahren haben. 

2^el des folgenden Beitrags ist es zu zeigen, wie durch die Verknüpfung von Netzplantechnik und wissensbasierten Tech- 
niken das Multiprojektmanagement umfassender als bisher unterstützt werden kann. 

2. Einführung in die Problemstellung 



Projekte sind zeitlich begrenzte Vorhaben, die sich durch Größe, Komplexität, Bedeutung und Einmaligkeit auszeichnen. 
Sie unterscheiden sich dadurch von regelmäßig anfallenden Aufgaben im Unternehmen. 

Die Entwicklung und Präzisierung von Konzeptionen für die Abwicklung von Projekten ging von regierungsamtlichen In- 
stitutionen der USA aus, beispielsweise der NASA, Navy, Army und Airforce. Dabei wurden Methoden und Techniken 
entwickelt, die die Projektleitungen bei ihren Aufgaben unterstützen, beispielsweise: 

- Projekt in Teilaktivitäten gliedern 

- Interdependenzen zwischen den Aktivitäten verdeutlichen 

- Projektablauf planen 

- Stand der Aktivitäten sammeln und aufbereiten 

- bei Abweichungen von der Planung Initiative zu korrektiven Maßnahmen ergreifen 

Die Planungs- und Kontrollmethoden von Projekten wurden durch die Einführung der Netzplantechnik entscheidend 
verbessert. Die Netzplantechnik ist ein Hilfsmittel zur anschaulichen Verdeutlichung der Reihenfolgebeziehungen zwi- 
schen den Projektaktivitäten. Das OR-Verfahren der Netzplantechnik unterstützt die Terminplanung. Zu jeder Aktivität 
wird die Zeitspanne berechnet, in der sie zu erledigen ist, um einen bestimmten Endtermin im Projekt zu halten. Außer- 
dem unterstützt die Netzplantechnik bei der Verwaltung des benötigten Personals, der Betriebsmittel, respektive der ge- 
planten imd realisierten Kosten. Es gibt zahlreiche softwaretechnische Lösungen, die vom PC bis zum Großrechner ver- 
fügbar sind. Andererseits wird die Projektleitung bei dem Erstellen eines Netzplanes und dem Ausregeln von Störungen 
im Projekt nur unzureichend unterstützt. Im folgenden werden die Probleme näher beschrieben. 
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2.1 Erstellen eines Netzplans 

Zu Beginn eines Projekts liegt eine mehr oder weniger genaue Vorhabensbeschreibimg mit den Projektzielen vor. Daran 
orientiert sich die Projektleitung im Rahmen der Projektstrukturierung. Sie erstellt eben Plan von den zu erledigenden 
Aufgaben, den Projektstrukturplan. Anschließend werden Vorgänge gebildet, die m eme zeitliche Rebenfolge zu emem 
Netzplan gebracht werden. Diese Tätigkeit setzt die Kreativität der Projektleitung voraus. Sie muß im Vorfeld der Pro- 
jektdurchführung wissen, wie das neue Vorhaben zu bearbeiten ist, d.h. welche Aufgaben m dem Projekt einzuplanen 
smd. Desweiteren muß sie eine Vorstellungsgabe von den Zusammenhängen zwischen den Aufgaben haben. Das gesamte 
Projekt wird bereits m Gedanken durchlaufen. 

Die Projektleitung wird m der kreativen Phase noch mcht maschmell unterstützt. Sie entwirft imd erarbeitet den Projekt- 
plan mit "Papier und Bleistift" oder am "Flip-Chart". Diese Vorarbeiten smd notwendig, um durch konventionelle Com- 
putersysteme der Netzplantechnik unterstützt zu werden. Sie helfen bei der Termmplanung imd Projektverfolgung. Eme 
ungenaue oder fehlerbehaftete Projektplanung sowie Unwägbarkeiten im Projektumfeld führen zu erhöhten Kosten oder 
Verzögerungen im Projekt. Deshalb ist die wissensbasierte Unterstützung der Projektleitung schon m dieser Phase be- 
deutend. 

Die Unterstützung der Planung einzeber Projekte wird von NETEX wissensbasiert unterstützt. In diesem Beitrag soll 
das Problem nur erwähnt, jedoch nicht weiter darauf eingegangen werden. 

22 Ausregelung von Störungen 



Das Multiprojektmanagement ist dadurch charakterisiert, daß die zur Durchfübung der Projekte notwendigen Betriebs-, 
Personal- und Finanzmittel gleichzeitig von meberen Projekten beansprucht werden. Das fübt zu eber Konkurrenz der 
Projektleitungen um die begrenzt vorhandenen Mittel. Es ist die Aufgabe des Multiprojektmanagements, die Mittel der- 
art auf die Projekte zu verteilen, daß ebe bsgesamt wirtschaftliche Lösung erzielt wird. Es besteht ständig Handlungsbe- 
darf; einerseits müssen neue Projekte berücksichtigt werden, die sich erstmals um Mittel bewerben, andererseits sind es 
laufende Projekte, die aufgrund von unvorhergesehenen Ereignissen zusätzliche Mittel beanspruchen. In der Regel sbd 
die vorhandenen Ressourcen schon belastet oder gar überlastet, sodaß ebe Anpassung an die neue Situation notwendig 
wird. Bei Projekten, denen mcht genügend Kapazität zur rechten Zeit zur Verfügung steht, fübt das zu Störungen, bei- 
spielsweise Termbverzögerungen. 

Unter der Projektmanagement-Software findet man keb Hilfsmittel, das der Projektleitung die Ursachen eber Störung 
im Projektablauf transparent macht und ib bei der Störungsausregelung im eigenen Projekt imd mit anderen Projekten 
konkrete Handlungsvarianten aufzeigt. Es wird immer ebe erfabene Projektleitung vorausgesetzt, die es versteht, auf 
Störungen zu reagieren. Mit dem wissensbasierten System NETEX soU das Multiprojektmanagement umfassender als 
bisher auch in diesem Bereich unterstützt werden. 




57 



3. Das Netzplantechnik-Expertensystem NETEX 
3.1 Das Anwendungsumfeld von NETEX 

Die folgende Graphik zeigt Aufgaben, die bei der Abwicklung von Projekten durchgefuhrt werden. Außerdem geht dar- 
aus hervor, in welchen Bereichen das Projektmanagement künftig durch wissensbasierte Techniken und die Netzplan- 
technik unterstützt werden soll. 
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32 Hard- und Softwareumgebung von NETEX 



Bei der Auswahl der Architektur für das Wirksystem NETEX sind drei Sachverhalte zu beachten. Erstens ist ein hohes 
Datenvolumen zur Bearbeitung aller Projekte zu verarbeiten. Zweitens ist ein bisher auf dem Host entwickeltes Netz- 
plantechniksystem in das wissensbasierte Gesamtsystem zu integrieren. Drittens werden hohe Erwartungen an die graphi- 
sche Aufbereitung und Bearbeitung der Projektdaten gestellt. 

Es bietet sich deshalb ein verteiltes wissensbasiertes System auf dem Host und PC an. Der Host bietet die Vorteile des 
zentralen Zugriffs auf alle Projektdaten, während der PC Vorteile bei der graphischen Aufbereitung der Daten und der 
Benutzerschnittstelle bietet. Die geplanten und derzeitigen Architekturen der Systeme sind in den Abbildungen 3.1 und 
3.2 ersichtheh. 

Das System NETEX wird im "Rapid Prototyping" entwickelt. Danach wird den zukünftigen Anwendern zu einem mög- 
lichst frühen Zeitpunkt ein Modell des künftigen Wirksystems auf einem Computer demonstriert. In dem Modell werden 
die wichtigsten Konzepte zur Problemlösung realisiert, nicht jedoch alle Funktionen. Efiüzienz, Sicherheit und Zuverläs- 
sigkeit des Prototyps werden bei der Entwicklung vernachlässigt. Der Entwickler erfährt sehr schnell, ob er das Konzept 
richtig übertragen hat und ob der Anwender sich durch das Konzept hinreichend unterstützt fühlt. Mit dieser Vorge- 
hensweise kann auf Änderungen und Wünsche frühzeitig Einfluß genommen werden. 

Das System wird auf einer leistungsfähigen Entwicklungsumgebung, bestehend aus einer Workstation der Firma 
Symbolics und dem Expertensystem-Entwicklungswerkzeug KEE (Knowledge Engineering Environement) entwickelt. 

4. Wissensbasierte Unterstützung der Stöningsausregelung mit NETEX 



Bei der Einplanung eines Projektes in das Multiprojektmanagement-System werden die benötigten Personalkapazitäten 
und Betriebsmittel vom verfügbaren Bestand abgebucht und reserviert. Dabei wird das Ziel verfolgt, die Projektlaufzeit 
zu minimieren. Oftmals ist das benötigte Personal erst zu einem späteren als dem geplanten 2Leitpunkt verfügbar, sodaß 
die Vorgänge erst zu einem späteren Termin durchgeführt werden können. Sofern davon kritische Vorgänge betroffen 
sind, verlängert sich die Projektlaufzeit. Unter Umständen ist der Auftraggeber damit nicht einverstanden. Er ist bestrebt 
die Projektlaufzeit zu verkürzen und wird einen Termin vorgeben, bis zu dem das Projektergebnis oder Teile davon vor- 
liegen sollen. 

Der Auftraggeber ruft durch sein Verhalten Störungen im Kapazitätshaushalt der Unternehmung hervor. Das Multipro- 
jektmanagement-System hat das Projekt mit der kürzest möglichen Laufzeit eingeplant und dabei die gegebenen Kapazi- 
tätsrestriktionen beachtet. Diese Restriktion wird bei einer Verkürzung der Laufzeit verletzt. In einem Projekt wird dem- 
nach eine Störung ausgelöst, wenn mehr Personalressourcen benötigt werden als vorhanden sind. Das betroffene Perso- 
nal ist dann überlastet. D.h. das Problem einer zu langen Projektlaufeeit ist in Wirklichkeit ein Kapazitätsproblem. Die 
Aufgabe des Multiprojektmanagements ist es, die Ursachen der Störungen im eigenen oder anderen Projekten zu finden 
und zu beheben. Beispielsweise ist die verspätete Abgabe eines Zwischenergebnisses die Ursache für Verzögerungen bei 
nachfolgenden Aufgaben im gleichen Projekt. Arbeitet ein Mitarbeiter in mehreren Projekten, dann kann ein Terminver- 
zug in einem Projekt zu Verzögerungen in anderen Projekten führen. 
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Abb. 3.2 Architektur des derzeitigen Systems NETEX 
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Die Projektleitung hat drei Parameter, an denen sie eine Störung ausregeln kann. Es sind die Parameter "Qualität und 
Quantität der Arbeitsergebnisse", "Termine" sowie "Personalaufwand xmd Kosten", die sich gegenseitig beeinflussen. Bei- 
spielsweise können durch die Erhöhung des eingesetzten Personals evtl. Termine eingehalten werden. Die Senkung der 
Anforderungen an einzelne Arbeitsergebnisse kann Kosten und/oder eingesetztes Personal senken. 

Die heutige Netzplantechnik-Software berücksichtigt die Parameter "Termine” und "Personalaufwand und Kosten". Sie 
unterstützt die Terminplanung imter Einhaltung von End- und Zwischenterminen sowie die Qualität und Quantität des 
Arbeitsergebnisses. Die Projektleitung kann damit den Personalaufwand und die Kosten ausregeln. Weiterhin kann mit 
der Netzplantechnik-Software die gleichmäßige Auslastung des Personals unter Einhaltung der Projektdauer geplant 
werden. Dabei wird ebenfalls von einer unveränderlichen Qualität und Quantität der Arbeitsergebnisse ausgegangen. 

Parameter zur Steuerung von Projekten 




Personalaufwand 
& Kosten 



Termine 



^tzplajtechnik 



Qualität & Quantität 
der Arbeitsergebnisse 



Die Netzplantechnik kann bei der Störungsausregelung durch Einbeziehung des Parameters Qualität und Quantität der 
Arbeitsergebnisse erweitert werden. Dies ermöglicht die Verknüpfung der Netzplantechnik mit wissensbasierten Techni- 
ken. 



4.1 Transparenz der Störungsursache 



In diesem Abschnitt wird vorgestellt, wie einer Projektleitung die Ursache einer Störung transparent aufbereitet werden 
kann. 

a) Falls bei der Planung keine Termine gesetzt wurden, treten keine Störungen durch Überlastfälle auf. Allerdings 
kann das Projekt mit erheblichen Verzögerungen im Ablauf eingeplant sein. Eine Verzögerung des Projektablaufs 
kann vom System ermittelt werden, indem die Planung mit frühest möglichem Beginntermm und frei verfügbaren 
Kapazitäten, der Planung unter den realen Gegebenheiten gegenübergestellt wird. Dabei ist es interessant, sich die 
erste Verzögerung zu betrachten, die eine Ursache für weitere Verspätungen sein kann. Das Ergebnis wird in ei- 
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ner Übersicht aufbereitet: 



Vorgang 


Aufgabenträger 


frühester Begumtermin 


geplanter Beginn 


V25 


AT-UVW 


10.10.90 


20.10.90 



Vorgang 


Projekt 


gesamter Puffer [T] 


Vl2 




25 


^25 


^2 


0 



RftLa^tiinfsdlayramm von AT-UVW 




10.10.90 



20, 10. 90 



Zeit 



100 % 



b) Eine Überlast bedeutet, daß ein Aufgabenträger für einen Vorgang eingeplant wurde, der sich terminlich nicht 
länger verschieben läßt und die täglich verfügbare Kapazität des Au^benträgers nicht ausreicht, den Vorgang 
vollständig zu bearbeiten. Die Wahrscheinlichkeit ist groß, daß die vom überlasteten Aufgabenträger bearbeiteten 
Vorgänge in zeitlichen Verzug geraten. Bei Vorgängen auf dem kritischen Pfad wirkt sich das direkt auf die 
nachfolgenden Vorgänge und die Projektlaufzeit aus. Bei nichtkritischen Vorgängen kann der 2^itverzug mit dem 
verfügbaren gesamten Puffer ausgeglichen werden. Hier sind ebenfalls Störungen denkbar. Der Vorgang kann 
zwar über einen Puffer verfügen, aber der Aufgabenträger muß nicht auch diesen zeitlichen Spielramn haben. Er 
kann bereits mit anderen Aufgaben belastet sein. Demzufolge ist es sinnvoll, den ersten und danach jeden 
folgenden Überlastfall im Projekt zu analysieren und die Projektleitung auf die Ursachen hinzuweisen. Die 
Projektleitung erhält vom System folgende Übersicht und ein Belastungsdiagramm: 



Überlast 


Aufg.-Träg. 


Vorgang 


Projekt 


Kapaz. 


Zeitraum 


ges. Pu£fer[T] 


150% 


AT-XYZ 


Vll 




50% 


7. Woche 


0 






V23 


P2 


90% 


7. Woche 


10 



Aus der Übersicht geht hervor, welche Vorgänge aus welchen Projekten von der Störung betroffen sind. 
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Der erste Überlastfall tritt bei dem Aufgabenträger AT-XYZ auf. Er ist in der 7. Woche mit den Vorgängen 
im Projekt zu 50% und mit V 23 im Projekt ?2 zu 90% ausgelastet. Der Vorgang V^^^ hat keinen Gesamtpuffer, 
d.h. er ist kritisch. Die Projektleitung würde bei der Durchführung von Projekt P^ als erstes mit dieser 
Überlastung konfrontiert. Die Störimg kann eine Verzögerung im Projektablauf verursachen und muß von der 
Projektleitung ausgeregelt werden. 

42 Handlungsvarianten zur Störungsausregelung 

Die Projektleitung muß die Initiative zur Ausregelung der Störungen ergreifen. Der Projektleitung werden 
Handlungsvarianten zur Auflösung der Störungen vom System vorgeschlagen. Die Projektleitung wählt die 
geeignetste Lösung frei aus. Die folgende Tabelle gibt einen Überblick über die Handlungsvarianten, von denen 
einige im folgenden ausführlich beschrieben werden. Die Lösung wird an einem Beispiel verdeutlicht. 
Anschließend wird das Lösungsverfahren beschrieben. 



Ausregelung im selben Projekt 



zeithche Anpassung: 

- Überlappung 

- Parallelisierung 
(Anordnungsbeziehung ändern, 
Planungsketten eines Aufg.-Träg. auflösen) 



kaoazitätsmäßige Anpassung: 

- Überstunden 

- Intensität erhöhen 

- Fremdvergabe 

- Grundlast zurückstellen 

inhaltlirhft Anpassung: 

- Aufgabenpaket verfeinern 
(Ergebnis stufenweise einführen, 

Aufg. mit mehreren Aufg.-Träg. verfeinern) 

- Anforderungen an das Arbeitsergebnis senken 



Multiprojektmanagement-Ausregelungen 



zeitliche Anpassung: 

- Pufferzeit in anderen Proj. ausnutzen 

kapazitätsmäßige Anpassung: 

- neue Aufgabenträger einsetzen 

- Aufgaben auf andere Aufgabenträger 
verlagern 

inhaltliche Anpassung: 

- Andere Projekte umplanen 
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42.1 Ausregelungen im selben Projekt (Einzelprojektfoll) 



Überlappung von Vorgängen: 

Für gewöhnlich beginnt die Bearbeitung eines Vorgangs, wenn sämtliche Arbeitsergebnisse der Vorgänger vorhegen. Die 
Bearbeitimg einzelner Vorgänge kann unter Zeitdruck vorgezogen werden, sodaß sie sich mit ihren Vorgängern teilweise 
überlappen. Das Wissen darüber, welche Vorgänge vorgezogen werden können, wird in "Wenn- Dann"-Regeln abgelegt. 

Parallelisierung von Vorgängen: 

a) Anordnungsbeziehung ändern: 

Falls im Projekt ein Zeitverzug vorhegt, kann dieser zum Teil durch ParaUelisierung von Vorgängen verringert werden, 
beispielsweise können Vorgänge zum Testen oder Dokumentieren eines Arbeitsergebnisses unter Zeitdruck nachträghch 
erledigt und mit dem nächsten Vorgang begonnen werden. Bei dem Projektpartner zeigte sich, daß bei bestimmten Tests 
nur äußerst selten Fehler festgesteht wurden. Deshalb geht man in derartigen SonderfäUen mit der Parahelisienmg ein 
geringes Risiko ein. 

Diese Art der Störungsausregelung ist aus der Fertigung bekannt. Unter Zeitdruck wird das Material bereits 
weiterverarbeitet, ehe das Ergebnis der QuahtätskontroUe vorhegt. Regeln verarbeiten das Wissen über die Vorgänge, ob 
sie parahelisierbar sind oder nicht. 

b) Planungsketten eines Aufgabenträgers auflösen: 

Bei dem Projektpartner wurden Vorgänge sequenzieU eingeplant, obwohl diese zeithch nicht voneinander abhängig 
waren. Für diese Tätigkeit war nur ein Aufgabenträger vorgesehen, der sie in dieser Reihenfolge bearbeiten sohte. Ein 
Terminverzug kann durch parahele Bearbeitung der Vorgänge mit unterschiedhchem Personal aufgelöst werden. 

Überstunden oder Intensität erhöhen: 

Die Einführung von Überstunden steht eine Maßnahme dar, mit der die verfügbare Kapazität erweitert wird. Weiterhin 
kann die zu erledigende Aufgabe mit erhöhter Intensität durchgeführt werden, d.h. schneUer als geplant. 

Fremdvergabe: 

Der Projektpartner vergibt häufig Aufträge an Fremdfirmen. Einerseits sind die Finnen auf diese Aufgaben spezialisiert, 
andererseits sind bei dem Projektpartner nicht genügend eigene Aufgabenträger verfügbar. Im letzten Fall kann das 
System Erfahnmgen einbringen und eigene Vorschläge machen, z.B. 

Das Aufgabenpaket X, beispielsweise Programmierung, befindet sich auf dem kritischen Pfad und die eigenen 
Aufgabenträger sind erst später verfügbar. In der Vergangenheit wurde das Aufgabenpaket X an die Firma Y 
vergeben, mit der gute Erfahrungen gemacht wurden. 
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Gnindlast zurückstellen: 

Die Grundlast teilt sich in einen verschiebbaren und einen fixen Anteil auf. Bei Kapazitätsengpässen wird ein 
Aufgabenträger von der verschiebbaren Grundlast entlastet, beispielsweise Tagespost beantworten. 

Aufgabenpaket verfeinern: 

a) Arbeitsergebnis stufenweise einführen: 

Wenn ein gesetzter Endtermin voraussichtlich nicht gehalten werden kann, dann muß geprüft werden, ob der Endtermin 
für alle Projektergebnisse gilt. Eventuell sind bestimmte Ergebnisse unkritisch und können später fertiggestellt werden. 

Bei dem Projektpartner ist Wissen darüber verfügbar, welche Teile einer DV-Anwendung in welcher Dringlichkeit 
einzuführen sind. Beispielsweise hat die Schnittstelle zum DV-Anwender eine höhere Priorität als die Anbindung von 
Peripheriegeräten an das Wirksystem. Das System schlägt der Projektleitung vor, die Projektstruktur entsprechend zu 
verfeinern und die Endtermine neu zu setzen. 

b) Aufgabe mit mehreren Aufgabenträgem verfeinern: 

Erfahrene Projektleitungen haben immer wiederkehrende Projektabläufe zu einem groben Aufgabenpaket 
zusammengefaßt. Der Einfachheit halber planen sie ihre Projekte, bezüglich dieser Aufgaben, nur noch auf dem groben 
Niveau. Bei unkritischen Aufgaben und Aufgabenträgem ist gegen dieses Vorgehen nichts einzuwenden. Das System 
unterstützt bei Terminverzug oder kritischen Aufgabenträgem die Verfeinerung der Planung. Es erkennt den 
Handlungsbedarf und hat das Wissen, wie diese Aufgabenpakete zergliedert werden können. 

Anforderungen an das Arbeitsergebnis senken: 

Der Auftraggeber kann bei Projektstörungen die Anforderungen an einzelne Arbeitsergebnisse senken. Dadurch 
reduziert sich der Aufwand, mit dem das Ergebnis erbracht wird. Das System kann den Vorschlag machen: 

In einem vergangenen Projekt wurde bei dem Aufgabenpaket "Programmierung" auf die Realisienmg der 
- Help-Funktion verzichtet. 

Dadurch kann der Aufgabenträger AT-XYZ um 20 Manntage entlastet und das Aufgabenpaket 25 Tage 
früher beendet werden. 



422 Multiprojektmanagement-Ausregdungen 



Priorität setzen: 

Gegeben sei der Fall, daß die Projekte A und B von der gleichen Projektleitung gemanaged werden. Bei der Einlastung 
des Projekts A kommt es bei einem Aufgabenträger zur Überlast. Das Projekt A kollidiert mit einer Aufgabe aus Projekt 
B. Es liegt im Ermessen der Projektleitung zu entscheiden, welchem Projekt sie die höhere Priorität gibt. Der Vorschlag 
des Systems bezüglich des Prioritätsvorzugs wird demnach auch der Projektleitung überlassen. 
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Pufferzeit in anderen Projekten ausnutzen: 

In der konventionellen Netzplantechnik-Software wird versucht, die Überlast eines Aufgabenträgers derart ausgeregelt, 
daß alle zum kritischen Zeitpunkt eingeplanten Vorgänge entlang der verfügbaren Pufferzeit verschoben werden. 

Neuer Aufgabenträgen 

Ein Projektverzug soll aufgeholt werden, indem ein Teil der zukünftigen kritischen Vorgänge schneller durchgeführt 
wird. Es besteht für einige Vorgänge die Möglichkeit, das Ergebnis mit Überstunden des verfügbaren Personals oder mit 
einer höheren Arbeitsintensität, d.h. schneller als geplant zu erbringen. Außerdem können einige Aufgaben mit erhöhtem 
Personaleinsatz schneller durchgeführt werden. Das System stellt aus der Menge der kritischen Vorgänge eine Liste der 
teilbaren Vorgänge zusammen. Ein Vorgang ist teilbar, wenn er von mehreren Aufgabenträgem gleichzeitig durchführbar 
ist. Der Vorschlag des Systems lautet: 

Die Kapazitätserhöhimg durch zusätzliches eigenes Personal hat bei folgenden Vorgängen einen positiven Effekt. 



Vorgang 


Aufgaben- 

träger 


Gesamtauf- 
wand [MT] 


geplante 
Dauer [T] 


Effekt zusätzl. 
Aufgträger. [T] 


Program- 










mierung 


AT-ABC 


40 


60 


10 


Progr.-test 


AT-DEF 


10 


14 


2») 



*) Der Zeitbedarf für den Vorgang Programmtest könnte bei Erhöhung der Kapazität um einen weiteren 
Aufgabenträger um 4 Tage verkürzt werden. Bei einer Verkürzung der Durchlauf^it um mehr als 2 Tage liegt 
dieser Vorgang jedoch nicht mehr auf dem kritischen Pfad. 




Die Grafik veranschaulicht den Zusammenhang zwischen dem 2^itaufwand zur Erledigung der 
Progranunieraufgabe und den daran beteiligten Mitarbeitern. Der Zeitbedarf sinkt mit wachsender Anzahl 




der daran beteiligten Aufgabenträger. Der degressive Verlauf ergibt sich durch die erforderhche 
Einarbeitungszeit und dem erhöhten Kommunikationsaufwand. 



Vorgänge 




Die Grafik zeigt einen Balkenplan, in dem die Vorgänge entsprechend ihrer Anordnungsbeziehung 
verkettet sind. Der eingezeichnete Effekt ergibt sich aus der Erhöhung der Personalkapazität bei der 
Programmierung. 



Vorgänge 



Vertrieb ; 



I Schulung Vertrieb 
Doliuinentaiion [ 



Program m lest 
Progranimierung 

Effekt 



Zeit [T] 



Legende: 

Zeitreduzierung durch Erhöhung der Persona Ikapazität 
kritischen Vorgang 
unkritischer Vorgang 

Die Verkürzung der Bearbeitungszeit im Vorgang "Programmtest" wirkt sich nicht vollständig auf die 
Projektlaufzeit aus. Der Vorgang liegt nicht mehr auf dem kritischen Pfad. 

Im Unterschied dazu hat die Erhöhung der Mitarbeiterzahl im Bereich des Projektmanagements keinen nennenswerten 
Effekt. Mit zusätzlichen Mitarbeitern gibt es Schwierigkeiten bezüglich der Richtlinienkompetenz. 
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Vorschla 2 des Systems: 



Das Programmierteam kann durch den Aufgabenträger AT-LMN ergänzt werden, der noch freie Kapazität hat. 



WENN ein Vorgang auf dem kritischen Pfad liegt 

und durch das Merkmal "teilbar = ja" gekennzieichnet ist, 

DANN untersuche den Effekt T^ei Erhöhung der Kapazität um einen weiteren Aufgabenträger und 
weise ihn aus. 



In der Regel werden OR-Algorithmen angestoßen, beispielsweise zur Berechnung des kritischen Pfades. Weiterhin wird 
in der Regel Erfahrungswissen zum Projektinhalt verarbeitet, beispielsweise welche Vorgänge teilbar sind und welcher 
Effekt damit verbunden ist. 



Umplanung eines anderen Projekts: 



Zur Ausregelung einer Störung in einem Projekt soll ein anderes Projekt umgeplant werden, so daß eine insgesamt 
wirtschaftliche Lösung erzielt wird. 

Ein bedeutendes Projekt A gerät bezüglich der Programmieraufgaben unter Zeitdruck und benötigt dringend weitere 
Programmierkapazität. Es wird an einen speziellen Programmierer gedacht, der von seinen derzeitigen Aktivitäten im 
Projekt B freigestellt werden müßte. Dadurch würde sich das Kapazitätsproblem von Projekt A auf das Projekt B 
verlagern und müßte dort ausgeregelt werden. Das System NETEX erkennt, daß an der Aufgabe mehrere 
Programmierer beschäftigt waren. Es schlägt vor, daß die restlichen Programmierer die Aufgaben übernehmen. Die 
Maßnahme hat einen Zeitverzug im Projekt B zur Folge, der vom System ausgewiesen wird. Diesen Vorschlag zur 
Störungsausregelung genehmigt der zuständige Abteilungsleiter. 

Beispiel einer Regel: 

WENN ein Aufgabenträger aus einem bestimmten Vorgang ausscheidet 
und den Vorgang mehrere Aufgabenträger bearbeiten, 

DANN verteile den Personalaufwand des ausscheidenden Aufgabenträgers auf die 
restlichen Aufgabenträger 
und berechne die neue Projektlaufzeit. 

5. Zusammenfassung und Ausblick 



Wissensbasierte Techniken gestatten die schnelle Umsetzung von Rechneranwendungen in eine lauffähige Umgebung. 
Im Unterschied zur konventionellen Software, kann mit wissenbasierten Techniken inhaltliches Wissen zur Problemlö- 
sung verarbeitet werden. Das inhaltliche Wissen muß den Charakter der Wiederholbarkeit haben, d.h. es muß in einer 
ähnlichen Problemsituation wieder anwendbar sein. Ansonsten kann die Erfahrung nicht weiter genutzt werden. 

Die Erfahrungen beim Kooperationspartner haben gezeigt, daß in den Projekten immer wieder ähnliche Aufgabenstel- 
lungen auftreten. Die Störungen in den Projekten und die Projekte selbst, sind nicht durch vollständige Einmaligkeit ge- 
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kennzeichnet. Aus diesem Grund ist auch die Unterstützung der Projektstrukturierung und Ablaufplanung erfolgver- 
sprechend. 

Mit der Erstellung der NETEX-Prototypen werden weiterhin Erfahrungen in den beschriebenen Bereichen gesammelt. 
Der Prototyp zur Unterstützung der Projektplanung wird zur Zeit von Anwendern getestet, während der Test des Proto- 
typs zur Störungsausregelung im Herbst erfolgt. 
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Abstract 



Eine professionelle Projektabwicklung ist für die 
Wirtschaftlichkeit eines EDV-Pro jektes die 
Grundvoraussetzung. Um diese zu unterstützen und zu 
gewährleisten kamen in den letzten Jahren eine Vielzahl von 
Projektmanagement Werkzeugen auf den Markt. Jedoch gerade 
das für die Wirtschaftlichkeit so wichtige Gebiet der 
Kalkulation und Kostenrechnung eines Projektes blieb in der 
Software-Branche in seiner Entwicklung weitgehend stehen. 



Das hier vorgestellte Expertensystem soll nun auch auf 
diesem Gebiet Projektmanagern Unterstützung bieten. Auf 
Basis der Function-Point Methode wurde ein System 
entwickelt mit dem der Aufwand für die Entwicklung von 
dialogorientierten DV-Anwendungen geschätzt werden kann. 



1 . Einleitxmg 



Wurden in den Anfangs jahren der EDV Umsätze und Gewinne 
überwiegend durch den Handel mit Hardware erzielt so nimmt 
in den letzten Jahren diese Stellung immer mehr die Soft- 
ware ein. Im Jahre 1989 betrugen die Aufwendungen für Soft- 
ware in der Bundesrepublik Deutschland und West-Berlin ca 
35 Mrd. DM, bei einem Verhältnis von Software- zu Hardware- 
Aufwendungen von 55:45. Studien der Marktforschungsunter- 
nehmen /INFRA89/ prophezeien für Mitte der 90er Jahre ein 
Ertragsverhältnis von 60:40 und ziehen für die Jahre nach 
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der Jahrhundertwende sogar ein Verhältnis von 80:20 zu Gun- 
sten der Software-Aufwendungen in Betracht. Dies sind Zah- 
len, die, falls sie auch nur annähernd eintreffen sollten, 
die Bedeutung von Software-Projekten für den Unternehmens- 
erfolg offen darlegen sollten. 



Doch trotz dieser Prognosen ist es geradezu erschreckend 
wie Projekte zur Entwicklung von Software in der heutigen 
Zeit abgewickelt werden. 



Das professionelle und wirtschaftliche Projektmanagement 
steckt heute in der Software-Branche immer noch in den Kin- 
derschuhen . 

Auf dem Gebiet der Kostenrechnung und Kalkulation von 
Software-Projekten steht die Entwicklung seit nahezu einem 
Jahrzehnt annähernd still. Kaum ein anderer Zweig der 
Wirtschaft kann es sich leisten eine Kosten-/Nutzenanalyse 
ihrer Produktionsgüter mit den heute bei der Durchführung 
von Software-Projekten herrschenden Praktiken 
durchzuführen . 

Wie lange Leiter von Software-Projekten die Verantwortung 
für ein solches Vorgehen noch übernehmen können ist 
sicherlich fraglich. Betrachtet man die Gewinn- und 
Verlustaufstellungen der EDV-Branche im Bereich Software- 
Projekte, so kommt man zur Einsicht, daß die Zeit für 
durchgreifende Veränderungen gekommen ist. Vor allem bei 
Großprojekten ist es heute fast schon die Regel, daß sie 
mehr außerhalb als innerhalb ihres Kosten- und Zeitbudgets 
liegen . 

Doch dies könnte und muß in Zukunft sicherlich geändert 
werden. Würde man besonders in den Anfangsstadien eines 
Projektes mehr Augenmerk auf die Wirtschaftlichkeit legen, 
so könnten grobe Fehleinschätzungen vermieden werden und 
somit dem eigenen Unternehmen viel Geld eingespart werden. 

Doch genau dazu bräuchte man eine realistische Kosten-/ 
Nutzenanalyse die dem für ein Projekt geschätzten Aufwand 
den zu erwartenden Gewinn gegenüberstellt. Dies und eine 
auf Wirtschaftlichkeit ausgerichtete Projektdurchführung 
würden dann auch Gewinne in der Software-Branche über die 
nächsten Jahre hinweg sichern. 

Das hier vorgestellte Konzept mit Hilfe eines 
Expertensystems gerade auf dem so risikoreichen Gebiet der 
Aufwandschätzung dem Projektmanager Untestützung zu 
leisten, erscheint zwar nur als ein kleiner Schritt, doch 
ist er für die Zukunft sicherlich richtungsweisend. 
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2 • Anwendungsiomf eld Aufwandschätziing 



2.1. Generelles Vorgehen 



Bei Betrachtung der heute verwendeten Verfahren zur 
Aufwandschätzung erkennt man, daß alle Vorgehensweisen von 
dem gleichen Grundprinzip ausgehen. 

Je nach Zeitpunkt, Anwendungsgebiet und Methodik des 
Verfahrens können einige Moduln des Grundkonzepts fehlen, 
doch die im folgenden Schema generelle Vorgehensweise 
zeichnet sich in jedem Verfahren ab. 



Aufgaben- 

stellung 



Strukt. 
der Aufgabe 


Ermitt.von 

Einflußfakt. 

Ausprägung 


Ermittlung 

Vergleichs- 

objekten 


Schätzung 

des 

Aufwands 



I I 



Faktische 

Information 



Projekt- 

veriauf 



Aufwand- 

erfassung 



Soll-/lst- 

Vergleich 



Analyse 
Abweichung 
u. Ursachen 



Bild "Allgemeines Vorgehen" 



In dem vorliegenden Konzept wurde der Function-Point 
Methode besondere Aufmerksamkeit gewidmet. Exemplarisch für 
die Vielzahl der Verfahren und Methoden wird daher im 
nächsten Kapitel das Vorgehen bei einer Schätzung mit Hilfe 
der Function-Point Methode etwas genauer erläutert . 
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2.2. Die Func^ion-Poinb Methode 



Die Function-Point Methode /NOKR86/ wurde von A.J. Albrecht 
bei der IBM in den USA entwickelt und wird seit 1981 in 
einer etwas modifizierten Form auch bei der IBM in 
Deutschland eingesetzt . 



Elementarfunktionen/ 






Dateneinheiten 






(Funktionsumfang) 






Systeman- 






forderungen 

aus 


Gewichts- 

punkte 


w Mann- 
r Monate 


Benutzersicht 




\ 






Einflußfaktoren 


Nachkalkulation 


(Nichtfunktionale Anforderungen, 




z.B. Qualitätsanforderungen) 





Bild "Verfahrenstechnik Function-Point Methode" 



Grundidee des Verfahrens ist die Annahme, daß eine 
Bewertung des Aufwands auf der Basis der 
Benutzeranforderungen durchgeführt werden kann. Das zu 
erstellende System wird dazu funktional aus der Sicht des 
Benutzers in die fünf Funktions- bzw. Datenob jekttypen 

Eingabedaten 

Abfragedaten 

Ausgabedaten 

Datenbestände 

Referenzdaten 

gegliedert . 

Die einzelnen Funktionen und Datenobjekte teilt man nach 
definierten Klassifikationskriterien in die drei Klassen 
"einfach", "mittel" und "komplex" und vergibt dadurch eine 
der Klasse und dem Funktionstyp entsprechende Anzahl von 
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Function-Points. In der Addition über alle auftretenden 
Funktionen und Datenobjekte ergeben diese Punkte die Summe 
der unbewerteten Function-Points. Im Anschluß klassifiziert 
man die vierzehn Einflußfaktoren 

Kommunikationseinrichtungen 

Datenverteilung im System 

Antwort szeit verhalten 

dto plus starke Systemlast 

Hohe Transaktionsrate 

Online-Dateneingabe 

Dialog plus komplexe Transaktionen 

Online-Dateipflege 

Komplexe Verarbeitung 

Wiederverwendung der Programme in anderen Anwendungen 

Konvertierungen 

Operating-Unterstützung 

Lokal getrennte Stationen 

Erleichterung des Änderungsdienstes 

Im Gegensatz zu der oben angesprochenen funktionalen 
Zerlegung sollen sie ein Projekt in seiner Gesamtheit 
abschätzen. Nach einer empirisch gewonnenen Formel 
berechnet sich aus der zunächst ermittelten Summe der 
unbewerteten Function-Points und der Summe der 

Einflußfaktoren die Anzahl der bewerteten Function-Points 
für diese Anwendung. Die Summe der unbewerteten Function- 
Points kann sich dabei um bis zu 35% nach oben bzw. nach 
unten verschieben. 

Mittels einer Erfahrungswertkurve, die eine Relation von 
Function-Points zu Mann-Monaten ist, gelangt man von der 
eben berechneten Anzahl an Function-Points zu dem 
entsprechenden Aufwand in Mann-Monaten. 

Nach Ablauf des Projektes fließen die Ergebnisse des Soll-/ 
Ist-Vergleichs in die Erfahrungswertkurve zurück und passen 
diese den gegebenen Entwicklungsbedingungen an. 



3 . Motivation 



Das Projekt entstand aus dem Antrieb in dem Gebiet der 
Aufwandschätzung Arbeitsformen und Strukturen zu schaffen, 
die ein effizientes und wirtschaftliches Arbeiten 
ermöglichen . 

Heute basieren Schätzungen zum großen Teil auf den 
Erfahrungen des Schätzers und auf einem von ihm selbst 
entwickelten Verfahren. Da oft nur das Ergebnis und nur in 
den seltensten Fällen der Weg zu diesem aufgezeichnet wird. 
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ist ein unternehmensweites Controlling so gut wie 
unmöglich. 

In diesem Gebiet sollte ein Tool entwickelt werden, das 
eine einheitliche und organisierte Arbeitsweise einführt. 
Die Ergebnisse werden dadurch austausch- und vergleichbar. 
Ein Schätzer kann an den Aufzeichnungen und Erfahrungen 
anderer partizipieren. Durch Analogieschlüsse kann die 
Genauigkeit der Ergebnisse verbessert werden. 



4 . Problemstellung 



4.1. Allgemeine Anforderungen an ein Schätzverfahren 



Grundsätzlich muß ein Verfahren zur Aufwandschätzung, 
gleich welchen Aufbaus auch immer, gewissen Anforderungen 
genügen, um eine akzeptable Genauigkeit der Schätzung zu 
ermöglichen. 

Ein Verfahren muß daher alle fünf elementaren Einflußgrößen 
der Software-Erstellung berücksichtigen. Qualität, 
Quantität, Projektdauer und Kosten konkurrieren nach 
/SNEED82/ um eine begrenzte Menge an Produktivität. 

Sind Quantität und Kosten relativ einfach zu beurteilen, so 
sind auf den anderen Teilgebieten nur sehr schwer operative 
und quantifizierbare Kriterien zu finden, die eine 
Beurteilung der Faktoren zulassen. 

Ein weiterer Punkt, der bei der Entwicklung eines 
Verfahrens zu berücksichtigen ist, ist die Auslegung des 
Verfahrens auf ein abgegrenztes Teilgebiet der EDV. Durch 
die verschiedenen Ansprüche und Entwicklungsanforderungen 
ist es nicht sinnvoll ein System für den gesamten Bereich 
zu erstellen. Schon allein die Gebiete konventionelle 
Programmierung, künstliche Intelligenz und 
objektorientierte Programmierung sind von ihren Ansätzen 
her zu verschieden um Projekte mit einem einzigen Verfahren 
beurteilen zu können. 

Ist ein Verfahren für ein Teilgebiet erstellt, so sollte es 
auch eine einheitliche Anwendung garantieren, insbesondere 
wenn es sich um ein dynamisches Verfahren handelt . Nur so 
kann die sich durch wiederholte Anwendung des Verfahrens 
entwickelnde Analogie positiven Einfluß auf die Genauigkeit 
der Ergebnisse nehmen. 
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Zusätzlich müssen alle Ergebnisse die im Laufe einer 
Schätzung erzielt werden dokumentiert werden, um dadurch 
die erzielten Ergebnisse transparent und nachvollziehbar zu 
machen . 

Letzter und sicherlich wichtigster Faktor ist die 
Zuverlässigkeit der Ergebnisse. Wie das Wort Schätzung 
bereits ausdrückt kann man keine 100% Genauigkeit der 
Ergebnisse erwarten. Um jedoch mit den Ergebnissen einer 
Schätzung arbeiten und kalkulieren zu können, sollte die 
Abweichung der Ergebnisse nicht mehr als 10-20% vom realen 
Wert betragen. 



4.2. Schätzen mit der Function-Point Methode 



Alle die oben genannten Anforderungen werden natürlich auch 
an ein Verfahren wie die Function-Point Methode gestellt. 
Doch während einige Anforderungen durch die Methode per se 
abgedeckt sind, treten zum anderen zusätzliche Probleme 
auf, die sich aus der Anwendung der Methode ergeben. Die 
Schätzmethode wurde, wie bereits oben erwähnt, Anfang der 
80er Jahre entwickelt und entspricht in ihrer vorliegenden 
Version nicht mehr den aktuellen Gegebenheiten der heute 
vorherrschenden Datenverarbeitung . 

Durch den Fortschritt der letzten zehn Jahre, in denen die 
Entwicklung der Function-Point Methode still stand, ergaben 
sich zum einen neue Faktoren, die heute den Aufwand 
beinflussen, während andere Faktoren nun eine 
untergeordnete Rolle spielen. 

Obwohl das Grundgerüst der Methode auch heute noch 
Gültigkeit beweist, entsprechen somit viele der Kriterien 
zur Beurteilung von Funktionen und Datenobjekte nicht mehr 
den heute relevanten Faktoren zur Einschätzung des 
Aufwands. Zur Beurteilung der Einflußfaktoren liegen bisher 
noch keine Kriterien vor, die eine Unterstützung bei der 
Klassifikation bieten könnten. 

Die Function-Point Methode legt zudem große Freiheiten in 
die Hände des Schätzers und verlangt dadurch vom 
Schätzenden einen reichen Erfahrungsschatz im Umgang mit 
der Methode. Da Aufwandschätzungen in einem Ausmaß, wie es 
bei Großprojekten der Fall ist, sicherlich nicht zu einer 
alltäglichen Beschäftigung von Projektmanagern gehören, 
besitzen nur wenige dieses Wissen. Dadurch entsteht eine 
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Fehlerquelle, die das Risiko einer Fehleinschätzung 
unweigerlich erhöht. 

Durch die unklar definierten Möglichkeiten bei der 
Beurteilung von Kriterien kann die Methode auch keine 
einheitliche Anwendung garantieren. Dies kann gerade bei 
einem dynamischen Verfahren, welches sich durch seine 
Anwendung an die Entwicklungsumgebung anpassen soll, zu 
Problemen führen. 

Ein kurzes Szenario einer Anwendung der Function-Point 
Methode verdeutlicht diese Problematik: 

Ein Schätzer hat die Anforderungen funktional aus 
Benutzersicht strukturiert und schätzt z.B. eine Funktion 
vom Typ "Eingabe" . Dazu wird er als erstes aufgefordert die 
Anzahl der Datenelementtypen abzuschätzen. Als Klassen 
stehen ihm "wenige", "mehrere" oder "viele" zu einer 
Beurteilung der Anzahl der Datenelementtypen zur Verfügung. 
Versetzt man sich in die Lage des Schätzers, so kommen 
unweigerlich einige Fragen auf : 



- Ist die Anzahl der Datenelementtypen für die Abschätzung 
des Aufwands heute noch relevant? 

- Wie viele Datenelementtypen sind "wenige" , "mehrere" oder 
"viele"? 



Findet er für diese Fragen noch Antworten so steht er wenig 
später vor dem nächsten Problem. Die Beurteilung der 
Funktion "Eingabe" beinhaltet gleichzeitig die Vergabe von 
drei, vier oder sechs Function-Points. Das Schema, nach dem 
sich diese Anzahl der Function-Points aus der Beurteilung 
der vorangegangenen Kriterien ergibt, ist unklar. Hier 
stellt sich bereits die nächste Frage: 



- Ist der Mittelwert die am häufigsten auftretende Klasse 
oder werden für jedes Beurteilungskriterium drei, vier 
oder sechs Function-Points vergeben ? 



Auf jeden Fall scheint eine Spannweite vom Faktor zwei von 
der einfachsten bis zur schwierigsten Eingabe fragwürdig. 

Um das Szenario noch etwas auszubauen kann man einen 
zweiten Schätzer hinzunehmen der sich mit dem ersten die 
Arbeit teilt und zieht dessen Verständnis von "wenige", 
"mehrere" und "viele" in die Betrachtung mit ein. Für einen 
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Einblick, wie problematisch sich so eine Schätzung 
gestalten kann, dürfte dies genügen. 

Aber mit Verwendung der Function-Point Methode verbinden 
sich auch positive Aspekte. 

Die Schätzung wird mit der Verwendung einer festen Methodik 
nachvollziehbar und somit argumentierbar. 

Die Basis auf der geschätzt wird sind funktional 
strukturierte Benutzeranforderungen, welche im Vergleich zu 
vielen anderen Verfahren, die als Basis z.B. auf LoC oder 
ähnliche Kriterien zugreifen, sich als weitaus geeigneter 
erweist . 

Das Verfahren ist dynamisch, d.h. die Ergebnisse eines 
Soll-/ Ist-Vergleichs zwischen geschätztem und real 
entstandenem Aufwand fliessen direkt in das Verfahren 
zurück und passen es der Umgebung in der es eingesetzt wird 
an. Es verbessert seine Schätzgenauigkeit praktisch 
selbständig. 

Ein zusätzlicher Vorteil den die Methode mit sich bringt, 
ist die gute Akzeptanz des Verfahrens sowohl in der 
Literatur als auch unter den EDV-Anwendern und Anbietern. 
Die Methode ist zweifelsohne geeignet, Schätzungen mit 
einer akzeptablen Genauigkeit durchzuführen. 

Die für eine Schätzung zu leistenden Vorarbeiten leiteten 
den Schätzer zu einer Zerlegung und Strukturierung der zu 
realisierenden Aufgabe an und vermindern so das in jeder 
Schätzung enthaltene Risiko. 

Die bei einer Schätzung entstehenden Aufzeichnungen 
dokumentieren automatisch den in der Schätzung 
berücksichtigten Funktionsumfang, sowie die Beurteilung der 
für die Kosten relevanten Faktoren. 

Insgesamt gesehen ist die Function-Point Methode mit allen 
ihren Vor- und Nachteilen ein Verfahren zur 
Aufwandschätzung, das in der richtigen Umgebung und bei 
korrekter Anwendung sehr wohl in der Lage ist, verläßliche 
Ergebnisse zu erzielen. 



5 . Aufgabenstellting 



Das Entwicklungsziel war ein Software-System zu entwickeln, 
das den folgenden Ansprüchen gerecht werden sollte. 
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1 . Ein Projektmanager hat mit dem System ein Tool zur Ver- 
fügung, daß ihm Unterstützung bei der Aufwandschätzung 
von Software-Projekten bietet. Dieses Tool soll Unter- 
stützung in einer Art und Weise leisten, daß damit auch 
weniger routinierte Schätzer in die Lage versetzt werden 
verläßliche Ergebnisse bei der Aufwandschätzung zu er- 
zielen. 

2. Das dem System zugrunde liegende Verfahren zur Schätzung 
soll den oben genannten Anforderungen genügen. Dazu ist 
dieses Verfahren neu zu konzipieren oder die Entwicklung 
auf einer bestehenden Verfahrenstechnik aufzusetzen. 

3. Neben der Abschätzung des Aufwands für Entwicklungsauf- 
gaben soll auch der für das Projektmanagement zu er- 
wartende Aufwand abgeschätzt werden. 

4. Das System soll einen Vorschlag machen wie die optimale 
Größe und Zusammensetzung eines Teams zur Realisierung 
des Projektes sein sollte. 

5. Das System soll trotz seiner Ausrichtung auf einen spe- 
zifischen Teilbereich der Datenverarbeitung variabel ge- 
nug sein um den Aufwand für ein weites Spektrum von An- 
wendungen schätzen zu können. Zudem soll es Möglichkei- 
ten bieten ohne großen Aufwand an verschiedene Entwick- 
lungsumgebungen adaptiert zu werden. 

6. Der Schätzvorgang und alle dabei erzielten Ergebnisse 
sollen vom System auf gezeichnet und zu einer Dokumenta- 
tion aufbereitet werden die gut strukturiert, einfach 
lesbar und von einer angemessenen äußeren Form ist . 



6 . Designentscheidtingen 



Als Basis für die Entwicklung der Verfahrenstechnik zur 
Aufwandschätzung wurde die Function-Point Methode 
verwendet. Sie brachte Voraussetzungen für eine schnelle 
und sinnvolle Weiterentwicklung mit sich. Dadurch konnte 
ein System entstehen, daß auch den heutigen Ansprüchen an 
ein Verfahren zur Aufwandschätzung gerecht werden kann. 

Einige der bereits oben als Vorteile der Methode 
erläuterten Verfahrensteile konnten direkt in die 
Entwicklung einf Hessen. 

Funktional strukturierte Benutzeranforderungen wurden als 
Basis der Schätzung beibehalten. Dies war ein Grundgerüst, 
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das zum einen den heutigen Anforderungen entsprach und zum 
anderen Möglichkeiten zur Weiterentwicklung anderer 
Verfahrensteile bot. 

Die Eigendynamik des Verfahrens sollte auch ein zukünftiger 
Bestandteil des Systems sein. Eine Anpassung an die heute 
bestehenden Verhältnisse kann mit dieser Verfahrenstechnik 
zum Teil automatisch abdeckt werden. 

Die Verbreitung und Anerkennung der Function-Point Methode 
versprach eine gewisse Akzeptanz bereits im Vorfeld der 
Entwicklung. 

Eine Modernisierung und Weiterentwicklung war vor allem bei 
der Klassifikation der Funktionen und Datenobjekte sowie im 
Bereich der Einflußfaktoren zu leisten. Hier waren 
geeignetere Kriterien zur Abschätzung des Aufwands zu 
finden und ihr Ausmaß auf den Einfluß einzustufen. 

Die Kalkulation des Aufwands für das Projektmanagement 
eines Projektes sowie ein Vorschlag für Größe und 
Zusammensetzung eines Projektteams sind in der Function- 
Point Methode nicht berücksichtigt. 

Die Verfahrenstechnik des zu erstellenden Systems sollte 
eine Kombination sein. Mit Hilfe des Wissens und den 
Erfahrungen routinierter Schätzer sollte zum einen die 
Function-Point Methode auf heutige Bedürfnisse 
weiterentwickelt und zum anderen mit dem Wissen über die 
Anwendung vereint werden. Die Funktionalität, die in der 
Function-Point Methode nicht enthalten war, war neu zu 
entwickeln und in das System zu integrieren. 



Das Software-System als Expertensystem zu realisieren lag 
in Anbetracht des Wissensgebiets Aufwandschätzung nahe. Die 
Trennung von Wissensbank und Inferenzkomponente schien 
gerade bei dieser Anwendung sinnvoll. 

Der Erfahrungsschatz routinierter Schätzer ruht meist auf 
persönlichen Erfahrungen und drückt sich mehr durch 
Heuristiken und Faustregeln aus als durch ein festes 
Be rechnungs s chema . 

Zudem wurde mit einem Werkzeug zur EDV-techni sehen 
Unterstützung von Aufwandschätzungen ein Gebiet betreten 
auf dem bisher kaum Erfahrungen Vorlagen. Dadurch war mit 
einer Vielzahl von Änderungswünschen und Anregungen zur 
Weiterentwicklung zu rechnen. Um diese schnell integrieren 
zu können sowie die Systementwicklung möglichst offen und 
änderungsfreundlich zu gestalten, ist eine Umsetzung des 
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Wissens in die einfach zu lesende und wartende Wissensbank 
eines Expertensystems die adäquate Form. 



1 . Aspekt:e der Implemenbiemng 



Die Entwicklung wurde mit der regelbasierten Entwicklungs- 
Shell TWAICE durchgeführt. 

Sie war von einem inkrementellen Vorgehen gekennzeichnet. 
Werden die Phasen Entwurf^ Realisierung und Test bei der 
Erstellung von konventionellen Programmsystemen sequentiell 
durchlaufen, so waren die Phasen, die Wissenakquisition 
eingebettet, hier zyklisch angeordnet. 

Bei dieser Vorgehensweise wird das Wissensmodell 
schrittweise aufgebaut und in das System integriert. Ganz 
im Gegensatz zu einem modellbasierten Vorgehen, bei dem vor 
Beginn der Implementierung das komplette Wissensmodell 
erstellt wird. 




Bild ** Inkrementelles Phasenmodell" 



Durch die Verwendung der Expertensystem-Shell konnte sehr 
schnell ein erster Prototyp aufgebaut werden. Mit dessen 
Hilfe bekam der Experte einen Eindruck, wie sein Wissen in 
das System integriert und von diesem verarbeitet wurde. Im 
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Anschluß erweitert man pro Zyklus die Wissensbank 
sukzessive und erhält so einen neue Prototypen, der in eine 
Testphase eingeht . Die Entwicklung erreicht ihren Endpunkt 
wenn das System das, gemäß den Anforderungen definierte, 
Verhalten zeigt . 

Eine Vorgehensweise, die für diese Entwicklung 
entscheidende Vorteile mit sich brachte und einen schnellen 
und effizienten Aufbau des Expertensystems gewährleistete. 
Der aktuelle Entwicklungsstand war jederzeit einseh- und 
testbar. Durch die fortlaufende Validierung der Prototypen 
konnte ein Fehl verhalten des Systems frühzeitig erkannt und 
mit geringem Aufwand beseitigt werden. Für Expertensysteme 
ein wichtiger Punkt, denn gerade der Wissenstransfer vom 
Experten zum Knowledge-Engineer birgt erhebliche 
Fehlerquellen . 

Eine ganz besondere Bedeutung kommt bei diesem Vorgehen dem 
ersten Prototypen zu. 

In vielen Projekten soll er laut seiner Intention die 
Machbarkeit der Realisierung aufzeigen um dadurch die 
Gültigkeit der zuvor getroffenen Aussagen nachweisen. Doch 
sein Einfluß auf das Gesamtprojekt ist meist weitaus 
gravierender . 

Der Knowledge-Engineer steht vor dem Problem, mit möglichst 
wenig Aufwand einen Prototypen zu erstellen, der in seinem 
Design bereits so ausgereift ist, daß weite Teile direkt 
für die Weiterentwicklung beibehalten werden können. Denn 
bereits die ersten Festlegungen sind schon Design- 
Entscheidungen die im späteren Verlauf nur mit vermehrtem 
Aufwand abzuändern sind. Zudem zeigt die Erfahrung das 
einmal getroffene Festlegungen nur ungern revidiert werden. 



Unerwartete Probleme entstanden während der 
Pro jektdurchführung nur bei der Wissenakquisition. Will man 
möglichst viel Wissen in einem kurzen Zeitraum integrieren, 
so gelangt man sehr schnell zur Erkenntnis, daß der 
Flaschenhals dieser Absicht die Verfügbarkeit des Experten 
ist. Daraus entstand die Notwendigkeit mehrere Experten in 
die Wissensakquisition einzubeziehen. 

Probleme ergaben sich immer dann wenn verschieden Experten 
unterschiedliche Aussagen zu ein und der selben 
Problemstellung trafen. Um die verschiedenen Meinungen in 
Einklang zu bringen war vor allem psychologische Arbeit vom 
Knowledge-Engineer zu leisten. 
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Zur Entwicklung der Benutzeroberfläche mußte die 
Entwicklung der Wissensbasis weitgehend abgeschlossen sein. 

Um die Benutzerführung zu verbessern und die Anwendung 
übersichtlicher zu gestalten wurde auf die von der 
Expertensystem-Shell vorgegebene eine zusätzliche 
Oberfläche gelegt. Dadurch konnten die zu einem Themenkreis 
gehörenden Fragen dann auch zu abgeschlossenen 
Eingabeeinheiten gruppiert werden. Die Prologschnittstelle 
der Shell dient als Kommunikationspunkt zwischen der 
zusätzlichen Oberfläche und der Wissensbasis. 



8. Aufbau des Systems 



8.1. Produktstatus 



Die Entwicklung der ersten Ausbaustufe ist vollständig 
abgeschlossen und das System für den Feldtest freigegeben. 
Durch den Einsatz des Systems in verschiedensten Projekten 
werden jetzt Änderungswünsche und Anregungen zur 
Weiterentwicklung der Anwender auf genommen. Diese können in 
Durch die Verwendung der Expertensystem-Shell konnte sehr 
schnell ein erster Prototyp aufgebaut werden. Mit dessen 
Hilfe bekam der Experte einen Eindruck, wie sein Wissen in 
das System integriert und von diesem verarbeitet wurde. Im 
Anschluß erweitert man pro Zyklus die Wissensbank 
sukzessive und erhält so einen neue Prototypen, der in eine 
Testphase eingeht . Die Entwicklung erreicht ihren Endpunkt 
wenn das System das, gemäß den Anforderungen definierte, 
Verhalten zeigt . 

Durch die Verwendung der Expertensystem-Shell konnte sehr 
schnell ein erster Prototyp aufgebaut werden. Mit dessen 
Hilfe bekam der Experte einen Eindruck, wie sein Wissen in 
das System integriert und von diesem verarbeitet wurde. Im 
Anschluß erweitert man pro Zyklus die Wissensbank 
sukzessive und erhält so einen neue Prototypen, der in eine 
Testphase eingeht. Die Entwicklung erreicht ihren Endpunkt 
wenn das System das, gemäß den Anforderungen definierte, 
Verhalten zeigt . 

die Entwicklung der nächsten Ausbaustufe integriert werden. 

Bis jetzt wurde in die Entwicklung ein Aufwand von ca. 8 MM 
investiert der sich auf die Phasen 
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- Einarbeitung und Entwicklung eines ersten Prototyp 

- Wissensakquisition, -implementierung und Test 

- Realisierung der Oberfläche 

verteilt . 



8.2. Systemkomponenten im Überblick 





Schätzdaten h 
aufnehnnen 1 

auswerten 1 


Nach- 

kalkulation 


( EXPERTENWISSEN 



ÜNiX - FILE - SYSTEM 



Bild "Systemkomponenten" 



8.3. Die Wissensbank 



Im Gegensatz zu der in einer Expertensystem-Shell 
integrierten und unveränderlichen Inferenzkomponente ist 
die Wissenbank der variable Teil des Expertensystems. In 
ihr wird das Fachwissen repräsentiert. Durch die 
Abarbeitung von Regeln, der vorgegebenen Taxoniestruktur 
und dem prozeduralen Prologteil steuert die Wissensbank 
dadurch die Anwendung. Support-Texte unterstützen den 
Anwender während einer Konsultation des Systems. 
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- Die Taxonomie spiegelt in ihrem Aufbau zum einen den Ver- 
lauf einer Schätzung und zum anderen die Objekte, die zur 
Gliederung eines Systems verwendet werden wieder. 

- Den zentralen Teil der Anwendung bildet jedoch das Regel- 
werk. Die Regeln speichern das Wissen zur Klassifikation 
der Funktionen, Datenobjekten und Einflußfaktoren. Durch 
sie wird sowohl die Auswahl als auch die Reihenfolge der 
Fragen bestimmt, die zur Abschätzung des Aufwands notwen- 
dig sind. Die Möglichkeiten zur Beantwortung der Fragen 
wurden dabei bewußt möglichst gering gehalten um eine 
subjektiv, einheitliche Anwendung des Systems zu gewähr- 
leisten. Das Wissen für die Ermittlung der optimalen Pro- 
jektteamgröße und -Zusammensetzung ist ebenfalls hier im- 
plementiert. 

- Das Wissen im prozeduralen Teil des Expertensystems dient 
überwiegend zur Abwicklung von mathematische Berechnungen 
sowie als Kommunikationspunkt von Regelwerk und Bediene- 
roberfläche. In Form der PROLOG-Prozeduren ist z.B. auch 
die Kalkulation des Aufwands für das Projektmanagement 
realisiert . 

- In Form von Tabellenwissen werden die bei einer Schätzung 
aufgenommenen Projektdaten abgespeichert. Zudem ist die 
Erfahrungswertkurve, eine Relation aus Function-Points 
und Mann-Monaten, als Tabelle implementiert. 

- Die während der Schätzung abrufbaren Support-Texte spei- 
chern deklaratives und deskriptives Wissen. Die kon- 
textabhängigen Hinweise zu den Eingabemöglichkeiten ent- 
halten Definitionen, weit er führende Erläuterungen und 
spiegeln dadurch auch die vom System verwendete Nomenkla- 
tur wieder. 



9 . Anwendlings er fahrungen 



Bis heute wurde das System in sechs verschiedenen Projekten 
eingesetzt. Die Einsatzorte und Fachgebiete verweisen auf 
sehr unterschiedliche Anwendungsgebiete, die Grundzüge 
dieser Projekte stimmten jedoch weitgehend überein. Alle 
Projekte wurden mit einer konventionellen Programmier- 
sprache realisiert, sind dialogorientiert und haben eine in 
ihrer Art vergleichbare nicht-graphische Oberfläche. 

Durch diese Anwendungen konnten sowohl positive Erfahrungen 
als auch kritische Anregungen gewonnen werden. 
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Eine für die weitergehende Entwicklung sehr erfreuliche 
Erfahrung ist das Interesse der Anwender die eine 
Unterstützung besonders auf diesem Gebiet mit offenen Armen 
empfangen. Der Grundstock für die Akzeptanz eines Tools als 
Hilfsmittel zur Aufwandschätzung ist gelegt. 

Die Zuverlässigkeit der Ergebnisse übertraf die 
Erwartungen. Das System erzielte Ergebnisse, die zwar meist 
höher lagen als die herkömmlichen Schätzungen der 
Projektverantwortlichen, die jedoch dadurch den realen 
Aufwand besser trafen. Die maximale Abweichung lag bei 25% 
vom tatsächlich entstandenen Aufwand. Durch die 
automatische Anpassung des Systems an seine 
Entwicklungsumgebung kann dieser Wert sicherlich noch 
verringert werden. 



München 

Hamburg 

Stuttgart 

Köln 

Düsseldorf 

Mannheim 



Kantinenabrechnungssystem 

Personalabrechnungssystem 

Arbeitszeiterfassung 

Produktionsplanungssystem 

Fertigungsinformationssystem 

Warenwirtschaftssystem 



Bild "Einsatzorte und Fachbereiche" 



Die für eine Schätzung notwendige Strukturierung brachte 
mehr Sicherheit in die Schätzung. Der Schätzer befaßt sich 
intensiver mit der gestellten Aufgabe. Das Risiko, daß 
Teilaufgaben nicht berücksichtigt werden oder völlig falsch 
eingeschätzt werden, sinkt dadurch. 

Der Mehraufwand, der durch die zu leistende Vorarbeit 
entsteht, wurde auf Grund der Wichtigkeit der Aufgabe 
bereitwillig toleriert. 
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Anlaß zu kritischen Äußerungen sowie Anregungen zur 
Weiterentwicklung boten vor allem die Gebiete Performance, 
Bedienungskomfort und Oberfläche. 

Hier wurde eine Verbesserung der Navigationsmöglichkeiten 
bei der Dateneingabe angesprochen . Weitere Anregungen 
betrafen funktionale Erweiterungen, die das Arbeiten mit 
dem gesamten Tool erleichtern würden. 

Um die Benutzersteuerung komfortabler zu gestalten sollte 
die vorhandene Oberfläche durch eine graphische 
Benutzerschnittstelle ersetzt sowie eine Steuerung der 
Anwendung durch Mouse Technik ermöglicht werden. 



10. Weiterentwicklxing 



In der ersten Ausbaustufe stellt das System eine Art 
Rohling eines Produktes dar. Die zu einer Schätzung 
notwendige Funktionalität ist vollständig vorhanden. Um das 
System jedoch zu einer vollen Produktreife zu führen ist 
eine Überarbeitung auf verschiedenen Gebieten notwendig. 

Die momentane Systemplattform UNIX erwies sich für ein 
Arbeitsgerät für Projektmanager einer Systemplattform DOS 
mit MS-Windows 3.0 oder OS/2 mit Presentation Manager 
unterlegen. Die Umstellung der Systemplattform ist mit der 
nächsten Ausbaustufe zu realisieren. Mit diesem Ausbau ist 
auch gleichzeitig die Umstellung auf eine graphische 
Oberfläche geplant . 

Die Funktionalität wird im Bereich der Verwaltung der Daten 
erweitert. Durch eine funktionale Trennung der Verwaltung 
der Schätzdaten von dem eigentlichen Schätzvorgang erhält 
der Anwender mehr Komfort und Freiheit in seiner 
Arbeitsweise . 

Der Aufwand soll in der nächsten Ausbaustufe nicht mehr für 
die Gesamtheit der Entwicklungsphasen berechnet werden, 
sondern eine Verteilung auf die Einzelphasen nach 
verschiedenen Entwicklungsmodellen zulassen. Für diese 
Verteilung sind intelligente Funktionen zu entwickeln, die 
die Anforderungen der einzelnen Phasen berücksichtigen. 

Zudem ist der Anschluß an ein CASE-System geplant. Die 
Ergebnisse der Analyse- und Designphase könnten dann direkt 
in das System übernommen werden und die momentan noch 
manuelle Strukturierung des zu entwickelnden Produkts 
ablösen . 
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Die Vor- und Nachteile einer Umstellung auf eine 
Programmiertechnik ohne Expertensystem-Shell sind bis zur 
Realisierung der nächsten Ausbaustufe noch zu analysieren. 

In Anbetracht dieser Aspekte würde dies zu einem Schätz- 
Tool führen, dessen Systemkomponenten eine, wie im Bild 
"Systemkomponenten Weiterentwicklung" auf gezeigte. Form 
haben könnten. 



1 graphische Oberfläche 


Schätz- 

daten 

verwalten 




Adapter 

CASE-Tool 




Schätz- 

daten 

auswerten 




Nach- 

kalkulation 


1 


EXPERTENWISSEN 



MS - DOS / UNIX - FILE - SYSTEM 



Bild "Systemkomponenten Weiterentwicklung" 



11. Fazit 



Das Fazit dieses Projektes soll, sofern man dies nach 
dieser Entwicklungszeit bereits schließen kann, aus einer 
Sicht gezogen werden, die sich vor allem auf die Vor- und 
Nachteile einer Expertensystementwicklung im Gegensatz zur 
Entwicklung eines konventionellen Systems stützt. 

Allerdings ist diese Betachtungsweise ausgelegt auf die 
ganz spezifische Sichtweise dieses Projekt. 

Es waren vor allem drei Aspekte, die sich für die 
Durchführung dieses Projektes als besonders geeignet 
erwiesen . 
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Die zyklische Anordnung der Entwicklungsphasen, das 
Arbeiten mit einer Expertensystem-Shell und die Darstellung 
des Wissens in der durch die Shell vorgegebenen Form. 

Die zyklische Entwicklung ermöglichte es Entwicklungsfehler 
sehr schnell aufzudecken und zu beheben. Geeignet, vor 
allem bei einem Projekt bei dem ein domänspezifischer Laie 
das Wissen eines Fachexperten aufnimmt das überwiegend als 
Gedankengut vorliegt. Die auftretenden Reibungsverluste 
durch Terminvereinbarungen, Reisen, mangelnde Verfügbarkeit 
der Personen sind dabei allerdings in Kauf zu nehmen und 
nicht zu unterschätzen. 

Als vorteilhaft erwies sich in diesem Zusammenhang auch die 
Darstellung des Wissens in Form von Regeln und 
Taxonomieobjekten . 

Regelwerk und Taxonomiebaum sind Repräsentationsformen die 
auch von Personen, die nur begrenzt über ein EDV- 
technisches Know-How verfügen, gelesen und verstanden 
werden können. Der Experte konnte erkennen wie sein Wissen 
aufbereitet und dargestellt wurde um es in eine für die 
Expertensystem-Shell verständliche Form zu bringen. Die 
Erklärungskomponente der Shell machte ihm zusätzlich die 
Art und Weise der Wissensverarbeitung deutlich. 

Die entstehende Wissensbank konnte dadurch immer wieder als 
Diskussionsgrundlage verwendet werden. Der Fachexperte 
erhielt so ein weitaus größeres Gefühl der Integration in 
den Entwicklungprozeß als dies bei der Entwicklung eines 
konventionellen Systems der Fall gewesen wäre. 

Dies alles zusammen rückte das System schon während seiner 
Entwicklung etwas näher zum Fachexperten hin was sich 
natürlich auch auf die spätere Akzeptanz positiv auswirkte. 

Nachteile ergaben sich in den Bereichen Performance, 
Portierbarkeit und Integration. 

Performanceverluste, vor allem aufgrund der Bindung des 
Endsystems an die Entwicklungs-Shell, die durch eine in- 
terpretative Verarbeitung des Wissen diese bedingt. 

Diese Kopplung hat auch negative Auswirkungen auf die 
Portierbarkeit des Systems. Das Expertensystem ist nur auf 
Systemplattformen lauffähig auf denen auch die 
Entwicklungs-Shell lauf fähig ist. 

Auch die Integration von Software, wie z.B. Datenbanken 
oder graphische Benutzeroberfächen, ist eingeschränkt. Bis 
heute ist noch keine Expertensystem-Shell auf dem Markt 
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verfügbar, die den Möglichkeiten der konventionellen 
Programmierung auf diesem Gebiet Paroli bieten kann. 

Als Fazit zeichnet sich daher für die Zukunft ein 
zweistufiger Weg der Systementwicklung ab, der in letzter 
Zeit bereits öfters in Erfahrungsberichten zur Entwicklung 
von Expertensystemen zu erkennen war. 

Ein System wird bis zu einer ersten wohl definierten 
Entwicklungsstufe mit Hilfe der Expertensystemtechnologie 
entwickelt. Die Verwendung einer Expertensystem-Shell 
veringert dabei zumeist den Entwicklungsaufwand zusätzlich. 

Das verspricht einen möglichst geringen 
Entwicklungsaufwand, eine geringe Fehlerquote, eine 
anwendernahe Entwicklung verbunden mit der Möglichkeit eine 
größtmögliche Menge von Wissen in einer Form aufzunehmen, 
die ohne großen Aufwand eine weitere Bearbeitung des 
Wissens zuläßt. 

Nach Fertigstellung der ersten Ausbaustufe gelangt man zu 
einem tiefgreifenden Einschnittspunkt im Projektverlauf. 

Das bisher erarbeitete wird einem Redesign unterworfen und 
aufgrund der aus der vorangegangenen Entwicklung gewonnenen 
Erfahrungen das System mit konventioneller 
Programmiertechnik entwickelt . 

Dieses kann nun ganz speziell auf die spezifischen 
Bedürfnisse der Problemstellung ausgelegt werden und somit 
vor allem von Seiten der Performance sowie Benutzerführung 
und -komfort weitaus mehr Möglichkeiten bieten. 

Die Ausnahme bilden Projekte, die zur Entwicklung von 
Systemen dienen, für die eine Vielzahl von Veränderungen 
oder eine rasche und fortlaufende Weiterentwicklung zu 
erwarten ist . 

Hier sollten die Vorteile, die ein Expertensystem mit der 
komfortablen Bearbeitung der Wissensbank bietet, ausgenützt 
werden um Änderungswünsche und Weiterentwicklungen 
kostensparend zu realisieren. Nachteile, die sich z.B. aus 
einer verminderten Performance ergeben können, sind dann 
allerdings in Kauf zu nehmen. Eine Erklärungskomponente, 
die in diesem Umfang in einem konventionellen Programm 
nicht als Standard zur Verfügung steht, kann vielleicht 
Vorteile auf einem anderen Gebiet schaffen. 

Steigenden Rechnerleistungen und der Preisverfall der 
Hardware werden in Zukunft den Marktanteil von 
Expertensystemen anheben. Doch der entscheidende Faktor für 
die zukünftige Marktposition werden die 
Integrationsmöglichkeiten dieser Technologie sein. 
Möglichkeiten, die es erlauben, Expertensysteme in einem 
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Datennetz zu betreiben, in Fremdsoftware einzubetten oder 
mit ihr kommunizieren zu lassen. 

Der technologische Ansatz ist vielversprechend, doch über 
diesen Punkt bis heute noch nicht hinausgekommen. 
Expertensysteme dienen immer noch mehr der Forschung als 
dem wirtschaftlichen Nutzen seiner Anwender. 

Doch vielleicht entstehen schon in naher Zukunft Software- 
Systeme, die zwar dann nicht Expertensysteme genannt 
werden, die von ihrer Logik her jedoch genau diese 
Technologie beinhalten. 
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1, Planung und Steuerung in der Fertigung 

Vorausschauende und steuernde Aktivitäten sind nicht nur im Gebiet 
der Produktion Voraussetzung für einen ökonomischen Erfolg. Sie 
erfreuen sich jedoch gerade in diesem Bereich seit einigen Jahren 
besonderen Interesses sowohl in der Praxis als auch in der For- 
schung. Gründe hierfür sind nicht nur in der wachsenden Komplexi- 
tät von Fertigungssystemen, in steigender Dynamik des Marktes in 
Bezug auf notwendig werdende Produktwechsel und in der sich ver- 
stärkenden Konkurrenz im Markt agierender Produktionsunternehmen 
zu suchen. Sie bestehen auch zum einen in der sehr anspruchsvollen 
Problemstruktur von Fertigungssystemen. Für sie ist es trotz jahr- 
zehntelangen Bemühens nicht gelungen, ausreichende Lösungsmethoden 
zu finden. Sie stellen sowohl für Forscher als auch für Praktiker 
- wenn auch aus verschiedenen Motiven - noch heute eine Herausfor- 
derung dar. Zum anderen haben sich gerade in den letzten Jahren 
weitgehend auf dem Gebiet der EDV Lösungsmöglichkeiten eröffnet, 
die bis in die siebziger Jahre hinein einfach nicht bestanden. 

Worin besteht nun diese besondere Komplexität der Produktion? Ohne 
den Anspruch auf Vollständigkeit stellen zu wollen, kann man si- 
cherlich die folgenden vier Faktoren nennen: 

a) Dimension. Dieser Begriff soll hier im Sinne der Zahl und 
Vielfalt der in Betracht zu ziehenden Teile, Operationen, Kom- 
binationsmöglichkeiten und Entscheidungsmöglichkeiten verstan- 
den werden. Die Zahl der zu planenden und zu steuernden Ele- 
mente beträgt bei der verarbeitenden Industrie gewöhnlich 
einige zig-Tausend oder geht gar in die Hundert-Tausende. 
D.h., daß Verfahren, die hier angewandt werden sollen, sich 
nicht in ihrer Effizienz auf kleine Probleme beschränken dür- 
fen, sondern daß sie auch noch bei solchen Problemgrößen mit 
wirtschaftlichem Aufwand zu akzeptablen Ergebnissen führen 
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müssen. Hierzu kommt der Umstand, daß Probleme im Bereich der 
Steuerung sozusagen ”on-line” gelöst werden müssen. D.h., man 
hat nicht die Möglichkeiten - wie z.B. bei der Tourenplanung - 
Probleme in der vorangehenden Nacht auf einem Großrechner zu 
lösen und die Lösungen dann am folgenden Tag zu implementie- 
ren. 

b) Unsicherheit des Umfeldes. Im Bereich der aggregierten Planung 
mit mittel- bis langfristigem Charakter ist verständlicher- 
weise zunächst die allgemeine Unsicherheit der Zukunft zu be- 
rücksichtigen, wie sie auch in anderen Unternehmensbereichen 
auf tritt. Allerdings sind oft die Auswirkungen solcher Unsi- 
cherheiten stärker als in anderen Bereichen: Während unvorher- 
gesehene Reaktionen oder Wünsche von Kunden im Vertriebsbe- 
reich unangenehmen zusätzlichen Planungsaufwand verursachen 
mag, sind in der Produktion die eigentlichen störenden Auswir- 
kungen sehr viel umfangreicher und folgenreicher. Hinzu kommen 
zwei weitere Unsicherheitsquellen, die in anderen Bereichen 
auch nicht in dieser Weise zu finden sind: Oft sind die Spezi- 
fikationen der zu erstellenden Produkte zu dem Zeitpunkt noch 
gar nicht bekannt, zudem mit der Planung oder sogar der Dispo- 
sition begonnen werden muß. Gerade bei "simultaneous 
engineering” ist diese Situation stark zu finden. Die zweite 
Unsicherheitsquelle ist das Fertigungssystem selbst. Maschinen 
fallen aus, Menschen werden krank, Rohstoffe haben nicht die 
erwartete Qualität, etc. 

c) Heterogenität des Problemcharakters . Hiermit möchte ich die 
"Dimensionalität” im Sinne der empirisch-kognitiven Entschei- 
dungstheorie bezeichnen, die bei der Produktionsplanung und 
-Steuerung zu berücksichtigen sind. So sind die oft als erstes 
ins Auge fallenden Probleme die der Generierung, Speicherung 
und Verarbeitung sehr großer Datenmengen. Einen ganz anderen 
Charakter hat das Problem der Bestimmung optimaler Reihenfol- 
gen in der Werkstattfertigung oder die Bestimmung optimaler 
Mischungen im Rahmen der Fertigung. Wiederum anders geartet - 
wenn auch eng verbunden mit den schon genannten Problemen - 
ist die Ermittlung und Erreichung optimaler Bestände, die Be- 
stimmung optimaler Schnittmuster, die Transportsteuerung im 
Fertigungsbereich, etc. Überlagert wird diese Problemvielfalt 
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darüber hinaus durch die Vielfalt der - teilweise simultan zu 
berücksichtigenden - Ziele und durch die Unterschiede in der 
Fristigkeit der Entscheidung. Diese reicht von der relativ 
groben, langfristigeren und leichter korrigierbaren Produk- 
tionsplanung bis hin zur extrem detaillierten kurzfristigen 
und kaum reversiblen Steuerung im eigentlichen Fertigungsbe- 
reich. 

d) Vielfalt der bestehenden Fertiaunasstrukturen. Obwohl es für 
viele sehr komplexe Produktionssysteme - man denke z.B. an die 
chemische Industrie - sehr ausgefeilte und gute Planungs- und 
Steuerungssysteme gibt, kann man wohl kaum davon sprechen, daß 
es einige wenige allgemein verwendbare Produktionssteuerungs- 
systeme gibt. Es wird sie wahrscheinlich auch nie geben. Der 
Grund hierfür ist die enorme Vielfalt verschiedener Ferti- 
gungstypen, die nach jeweils anderen Steuerungssystemen ver- 
langen. Zwar hat man in der Theorie verschiedene Systematiken, 
gegliedert nach der Fertigungsorganisation, der Produktart, 
den Steuerungsprinzipien, der Produktionszahl etc. erarbeitet. 
In der Praxis findet man allerdings meist Mischtypen, die 
teils historisch gewachsen, teils den jeweiligen Gegebenheiten 
entsprechend entworfen worden sind. Man kann daher sicher be- 
stimmte Planungs- und Steuerungssysteme oder Prinzipien für 
gegebene Produktionssysteme als nicht passend ausschließen. Es 
ist dagegen sehr schwer - wenn nicht unmöglich - ein am Markt 
angebotenes EDV-System ohne Modifikationen zur Steuerung ein- 
zusetzen. Dazu kommt, daß gerade im letzten Jahrzehnt aufgrund 
neu zur Verfügung stehender EDV-Technologie Fertigungs typen 
wie Fertigungszellen, flexible Fertigungssysteme etc. entstan- 
den sind, die vorher gar nicht bestanden. 



2. Klassische Planungs- und Steuerunasansätze des Ooerations 
Research 

Bei der Betrachtung klassischer Ansätze des OR zur Planung und 
Steuerung von Produktionssystemen ist sicherlich zwischen Theorie 
und Praxis zu unterscheiden. In der Theorie war - abgesehen von 
relativ vielen Modell- und Methoden-Vorschlägen der Lagerhaltungs- 
theorie - die Zahl der empfohlenen Methoden relativ begrenzt: Im 
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Planungsbereich wurden außer Pr ognosever fahren gewöhnlich lineares 
Programmieren zur Bestimmung optimaler Produktionsprogramme, opti- 
maler Mischungen etc. angeboten. Für speziellere Fragestellungen 
wurden auch Dynamische Programmierung, Branch & Bound oder Verfah- 
ren der ganzzahligen linearen Programmierung genannt. Die weitaus 
größte Zahl der Modelle war deterministisch, aggregiert und 
scharf. Hierzu kamen deterministische, optimierende oder heuristi- 
sche Verfahren für Probleme, wie den Bandabgleich bei Fließferti- 
gung. Im Bereich der Steuerung der mechanischen Fertigung gab es 
zum einen Reihenfolgemodelle, die aber zwangsläufig auf unreali- 
stisch kleine Probleme beschränkt waren. Daneben stand die umfang- 
reiche Literatur, in der der stochastische Charakter der Steue- 
rungsproblematik anerkannt wurde und die weitgehend lokale Priori- 
tätsregel-Steuerungen empfahl. Die Wirkung dieser Regeln wurde 
entweder simulativ untersucht oder aber aus vereinfachten Warte- 
schlangen-Modellen abgeleitet. Beispielhaft für diese Literatur 
der sechziger und siebziger Jahre sind Baker [1974], Hanssmann 
[1962], Muth and Thompson [1963], Fabrycky and Torgersen [1966], 
Zimmermann und Sovereign [1974]. Eine gewisse Sonderstellung 
nehmen die Arbeiten von Holt, Modigliani, Muth und Simon [1960] 
ein, die zwar nicht unbedingt als klassische OR- Autoren bezeichnet 
werden können, die aber einen beachtenswerten Einfluß auf 
Entwicklungen auf diesem Gebiet hatten. 

Die Praxis der Produktionsplanung und -Steuerung ist von der oben 
genannten Literatur meines Erachtens recht wenig beeinflußt wor- 
den. Dies ist teilweise sicher auf die zu dieser Zeit noch weniger 
leistungsfähige EDV (Hardware und Software) und auf Datenprobleme 
zurückzuführen. Jedoch selbst in Situationen, in denen die genann- 
ten OR-Ver fahren hätten Verwendung finden können, geschah dies 
meist nicht. Stattdessen entstanden in zunehmendem Maße PPS- 
Systeme, die sich primär dem offensichtlichen Problem, dem der Da- 
tenerfassung, -Speicherung und -Verarbeitung, widmeten. Sie waren 
und sind weitgehend den bis dahin geläufigen "manuellen” Steue- 
rungssystemen nachempfunden und nutzen nur in sehr geringem Maße 
das Potential anwendbarer optimierender oder heuristischer OR-Ver- 
fahren zur Verbesserung der Entscheidungsqualität. 

Die in den achtziger Jahren propagierten, aus dem neu erwachten 
Gebiet der Künstlichen Intelligenz stammenden Expertensysteme oder 
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wissensbasierten Systeme haben die bei den OR-Verfahren fest- 
zustellende Ignoranz durch die Praxis nicht wiederholt. Dies ist 
teilweise sicher auf die inzwischen weit verbesserte und verbrei- 
tetere EDV-ümwelt zurückzuführen. Allerdings scheint auch bei 
diesen Systemen häufig oder gar meist das bestehende OR-Potential 
ungenutzt zu bleiben. 

Ehe im letzten Abschnitt dieses Beitrages über attraktive Kombina- 
tionen von OR-Potentialen mit ES (Expertensystem) - Stärken ge- 
sprochen wird^ seien einige Bemerkungen zu existierenden ES er- 
laubt. 



3. Expertensvsteme in der Produktion 

Im Rahmen der wissensbasierten Systeme haben Expertensysteme (ES) 
in den letzten Jahren besonderes Interesse gefunden. Die Defini- 
tionen solcher Systeme reichen von "Expert Systems are problem- 
solving programs that solve substantial problems generally 
conceded as being difficult and reguiring expertise" [Stefik et 
al. 1982] bis hin zu "An expert System is regarded as the 
embodiment within a Computer of a knowledge-based component from 
an expert still in such a form that the System can off er 
intelligent advice or take an intelligent decision about a 
Processing function. A desirable additional characteristic, which 
many would consider fundamental, is the capability of the System, 
on demand, to justify its own line of reasoning in a manner 
directly intelligible by the inquirer. The style adopted to attain 
these characteristics is rule-based programming" [Holroyd 1985]. 

Betrachtet man viele der heute existierenden ES, so wird offen- 
sichtlich, daß in vielen Fällen lediglich eine programmtechnische 
Rechtfertigung dafür gegeben werden kann, ein EDV-System als ES zu 
bezeichnen: Nämlich die Tatsache, daß ansonsten wohl-strukturierte 
Problemlösungen, für die algorithmische Beschreibungen geliefert 
werden können, in einer speziellen Welse regelbasiert programmiert 
worden sind, so daß ihre Wartung, Modifikation und Verbesserung 
besonders einfach geschehen kann. Diese Art von ES soll allerdings 
hier nicht betrachtet werden. 
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Hier sollen auch keine weiteren Definitionen gegeben werden. 
Stattdessen sollen einige Charakteristika erwähnt werden, die si- 
cherlich unbestritten sind, und die besonders relevant für die 
folgenden Ausführungen sein werden: 

a) Die jeweiligen Anwendungsgebiete von ES sind relativ eng be- 
grenzt, schlecht strukturiert und unsicher, d.h., es sind ent- 
weder keine effizienten exakten Algorithmen vorhanden, um die 
Problemstellungen zu lösen, oder die Strukturen lassen sich 
nicht exakt mathematisch modellieren. 

b) ES beruhen - wenigstens teilweise - auf Expertenwissen, das 
entweder von menschlichen Experten oder aus anderer Quelle 
(Lehrbücher etc.) extrahiert worden ist. Dieses Wissen ist im 
ES gespeichert und wird zur Lösungsf indung benutzt. 

c) Ein ES hat die Fähigkeit logischen Schließens mit Hilfe des in 
ihm gespeicherten Wissens - in welcher Weise es auch in ihm ge- 
speichert sei. 

d) Das Interface des ES ist so gestaltet, daß es vom Benutzer ohne 
Einschaltung eines menschlichen Agenten benutzt werden kann. 

e) Da durch den heuristischen Charakter des Systems keine Optima- 
litätsgarantie gegeben werden kann, verfügt das ES über ein Er- 
klärungs- oder Rechtfertigungsmodul. 

Man wird sicherlich nicht sagen können, daß ES effizienter als 
entscheidungsunterstützende Systeme sind, die analytische optimie- 
rende Verfahren benutzen, wenn dies auch hin und wieder Vorkommen 
mag. Der Einsatz von ES scheint deshalb besonders dann sinnvoll zu 
sein, wenn für einen Problemkreis keine leistungsfähigen Modelle 
oder Lösungsverfahren zur Verfügung stehen. Gründe hierfür sind in 
den meisten Fällen die Existenz von Unsicherheit und/oder Komple- 
xität. "Unsicherheit” sei hier zunächst generisch für nicht-dicho- 
tome Strukturen verwandt, d.h. für Strukturen, die nicht adäquat 
durch zweiwertige Mode 11 sprachen abgebildet werden können, sondern 
die mehr vom Mehr-oder-weniger-Typ sind. 
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Komplexität kann in den verschiedensten Formen vorliegen: Kombina- 
torische Vielfalt, Nichtlinearität, existierende vielfältige Ab- 
hängigkeiten etc. Unsicherheit in oben erwähntem Sinne umfaßt 
stochastische Unsicherheit, wie sie mit Wahrscheinlichkeitstheo- 
rie, Evidenztheorie u.ä. zu modellieren ist, genauso wie Unschärfe 
und Vagheit, wie sie mit Hilfe z.B. der Möglichkeitstheorie, der 
Theorie unscharfer Mengen u.ä. adäquat quantitativ dargestellt 
werden kann, und wie sie sehr oft gerade bei "Expertenwissen” zu 
finden ist. Als Beispiele für diese Art von Unsicherheiten mögen 
folgende Aussagen dienen: 

"Die Wahrscheinlichkeit, das Ziel zu treffen, ist 0.6." 

Dies ist offensichtlich eine Aussage, die quantitative Wahrschein- 
lichkeiten enthält und die adäquat durch Verwendung von Kolmo- 
goroff sehen Wahrscheinlichkeitskalkülen modelliert werden kann. 

"Die Chancen, zu gewinnen, sind groß." 

Hier fehlen quantitative Wahrscheinlichkeitsangaben, und es wird 
bereits schwierig, ein angemessenes Wahrscheinlichkeitsmodell zu 
finden. 

"Wahrscheinlich machen wir einen guten Gewinn." 

Hier fehlen auch die quantitativen Wahrscheinlichkeiten. Darüber 
hinaus ist jedoch das Ereignis selbst (guter Gewinn) nicht scharf 
definiert. 

Betrachten wir schließlich die Aussage 

"Die Erfahrung des Experten A weist überzeugend darauf hin, daß B 
passieren wird, während Experte C davon überzeugt ist, daß B recht 
wenig wahrscheinlich ist" . 

wird sicherlich klar, daß wahrscheinlichkeitstheoretische Kalküle 
hier kaum zu einem angemessenen Modell führen. 

Liegen Unsicherheiten nicht-stochastischer Art vor, so reicht es 
im ES nicht aus, die Inferenz in deterministischer Weise durch- 
zuführen und parallel dazu Wahrscheinlichkeiten zu errechnen. 
Stattdessen sind Inferenzmethoden zu verwenden, die die direkte 
Verarbeitung von graduellen (im Gegensatz zu scharfen) Relationen 
und Komponenten erlauben. Hierzu sind vor allem die unscharfe Lo- 
gik, das approximative Schließen und das plausible Schließen zu 
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rechnen. Ihr Verhältnis zur dualen Logik kann wie folgt skizziert 
werden : 

In dualer Logik und allen davon abgeleiteten Verfahren werden die 
Operatoren (und, oder, Negation) gewöhnlich durch Wahrheitstafeln 
definiert, deren Wahrheitswerte die Werte 1 (wahr) oder 0 (falsch) 
annehmen können. Außerdem werden die als wahr oder falsch zu be- 
wertenden Komponenten (Aussagen) als scharf definiert angesehen 
(materielle Wahrheit) . In der unscharfen Logik wird die letztere 
Annahme beibehalten, während die Wahrheitswerte als linguistische 
Variable (Wahrheit) auf gef aßt werden. 

Im approximativen Schließen (approximate reasoning) macht man 
einen weiteren Schritt: Hier werden nicht nur die Wahrheitswerte 
als unscharfe Mengen auf gef aßt, sondern es ist auch möglich, daß 
die Aussagen selbst oder deren Komponenten durch unscharfe Mengen 
(linguistische Variable, unscharfe Quantoren wie "einige”, "we- 
nige”, "meist”, "oft” etc.) dargestellt werden. 

Beim plausiblen Schließen (plausible reasoning) schließlich läßt 
man darüber hinaus zu, daß die Komponenten in den Prämissen und 
Regeln nicht streng identisch sind. Hierzu zur Verdeutlichung ein 
einfaches Beispiel: 

Beispiel; 

/w> ^ 

Es seien A, A', B und B' sich unterscheidende unscharfe Mengen 
(Aussagen) . Im plausiblen Schließen können dann folgende Inferen- 
zen benutzt werden: 

Wenn A, dann B (Regel) 

A* ist wahr (Tatsache) 

Dann ist B^ wahr (Schluß) 

Da die Inhalte von Regel und Tatsache nicht identisch sind, konn- 
ten beim klassischen Vorgehen keinerlei Schlüsse gezogen werden. 
Auch beim plausiblen Schließen sind natürlich gewisse Informatio- 
nen über die Verhältnisse von A zu A* und von B zu B* erforder- 
lich. 




Zur Illustration: 
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Wenn Tomaten rot sind, sind sie reif (Regel) 

Diese Tomate ist sehr rot (Tatsache) 

Diese Tomate ist sehr reif (Schluß) 

Es wurde schon erwähnt, daß traditionelle PPS-Systeme aus den ge- 
nannten Gründen optimierende oder heuristische OR-Ansätze kaum 
verwenden. Es liegt nun nahe, hierzu wissensbasierte Ansätze zu 
versuchen, die menschliche Erfahrung mit leistungsfähiger elektro- 
nischer Datenverarbeitung verbinden. Drei Gruppen solcher Ansätze 
lassen sich hierbei unterscheiden: 

1. Ansätze, die punktuell wissensbasierte Systeme zur Lösung spe- 
zieller Aufgabenstellungen im Rahmen der Produktionssteuerung 
einsetzen. Gute Beispiele hierfür sind Opal [Bensana et al. 
1988], die Systeme Kodex und Ewaks [Mertens 1990], FELIS 
[INFORM 1990], u.a. 

2. Ansätze, die wissensbasierte Modelle zur Steuerung spezieller 
Typen von Fertigungssystemen einsetzen. 

3. Ansätze, die versuchen, allgemeinere Produkt ions typen (wie z.B. 
auftragsorientierte Werkstattfertigung) insgesamt wissensba- 
siert zu steuern. 

Die als dritte genannten Ansätze stehen erst am Anfang der Ent- 
wicklung, und es ist noch nicht abzusehen, inwieweit sie zum Er- 
folg führen werden. Es ist hierbei zu bedenken, daß ES eigentlich 
dazu gedacht sind, eng begrenzte Problembereiche abzudecken. Für 
die Gesamtsteuerung allgemeinerer Produktionstypen sind daher eher 
Systeme denkbar, die neben konventioneller PPS-Technologie eine 
Anzahl von ES in kooperativer Weise untereinander verbinden, um 
mehr punktuell bestehende PPS-Systeme zu verbessern. 

Ein anderer Ansatz ist der, klassische OR-Verfahren, unter Umstän- 
den in modifizierter praxisnaher Form, mit ES-Technologie zu ver- 
binden und mit PPS-Systemen, die die notwendige klassische Daten- 
verarbeitung übernehmen, zu vereinigen. Solche Systeme sollen hier 
als "hybride Systeme” bezeichnet werden. 
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4, Hybride Systeme zur Entscheidunasunterstützuna in der 
ProduXtion 

Wir wollen hier beispielhaft ein hybrides System beschreiben, das 
in die 2. Gruppe der oben genannten Ansätze einzuordnen ist. Es 
soll die planerischen und steuernden Funktionen für ein flexibles 
Fertigungssystem ( FMS ) unterstützen . 

Ein FMS ist eine Gruppe numerisch gesteuerter Werkzeugmaschinen, 
die untereinander mit Ein- und Ausgabestationen über eine rechner- 
gesteuerte Transporteinheit verbunden sind. 

"Flexibilität” bezieht sich hierbei vor allem auf folgende Punkte: 

1. Die Zusammensetzung der Aufträge (Teilemix) kann laufend geän- 
dert werden. 

2. Die Maschinenfolge der einzelnen Aufträge ist beliebig. 

3. Wegen des geringen Rüstaufwands kann das kurzfristige Produk- 
tionsprogramm geändert werden, ohne daß Änderungen in der Fer- 
tigung nötig sind. 

4. Langfristig kann auch eine in einem gewissen Rahmen modifi- 
zierte Produktpalette mit dem unveränderten Fertigungssystem 
bearbeitet werden. 

Um die Potentiale von FMS tatsächlich ausnutzen zu können, ist es 
sinnvoll, die Fertigungssteuerung so zu gestalten, daß z.B. in 
einem PPS-System die aggregierte Produktionsplanung durchgeführt 
wird, und daß für bestehende Fertigungszellen oder FMS dedizierte 
Steuerungssysteme vorgesehen werden. Das zentrale PPS-System lie- 
fert z.B. einen zeitrastermäßig groben, aber vollständigen Plan 
aller eingeplanten Aufträge (ohne Reihenfolgen) , während die dedi- 
zierten Systeme detaillierte Steuerungen für die FMS erzeugen, wo- 
bei als Ziele vorgesehen werden können: 
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1. Minimierung der Durchlaufzeiten. 

2. Minimierung der Verspätungen, bezogen auf interne oder externe 
geplante Fertigungszeiten. 

3. Maximierung der Maschinenauslastung. 

In dem hier betrachteten System sollen folgende Gebiete einge- 
schlossen werden: 

1 . Grobplanung . 

2. Einlastung in das FMS. 

3. Maschinenbelegung im FMS. 

Diese Einteilung folgt den schon oben erwähnten Strukturen klassi- 
scher PPS-Systeme, in denen Planung (mittel- und langfristig) von 
Steuerung (kurzfristig) getrennt wird. Dies ist hier besonders 
deswegen sinnvoll, weil die Charakteristiken dieser zwei Gebiete 
recht verschieden voneinander sind, und weil deshalb auch ver- 
schiedene Problemlösungsansätze verwendet werden sollten: 

Während die Ermittlung des Produktionsprogramms eine relativ gut 
strukturierte deterministische Problemstellung ohne kombinatori- 
sche Komplexität ist, für die man z.B. lineares Programmieren ein- 
setzen kann, sind die Gebiete 2 und 3 stärker stochastisch und 
enthalten die (kombinatorische) Reihenfolgeproblematik. Hier wird 
man sehr viel eher auf möglichst gute Heuristiken zurückgreifen 
müssen als im ersten Gebiet. Hierbei sind besonders die oft kon- 
fliktären Zielsetzungen zu beachten. Die Ansätze seien nun - für 
die zwei genannten Problemkreise getrennt - etwas detaillierter 
betrachtet : 

A. Terminplanung (Grobplanung) • 

Die Hauptaufgabe der Terminplanung ist, die vorliegenden Aufträge 
unter Berücksichtigung der Kapazitäten der FMS in zukünftige Zei- 
tintervalle einzuplanen. Das Ergebnis ist in zwei Hinsichten 
Grundlage für die nachfolgende Feinsteuerung: 

1. Durch die Aufteilung des Gesamtarbeitsumfanges auf einzelne 
Planperioden (Dekomposition) wird die Zahl der Aufträge pro Pe- 
riode (Größe des Teilproblems) und damit der notwendige Rechen- 
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aufwand pro Periode der folgenden Feinsteuerung wesentlich re- 
duziert. 

2. Die Terminierung kann als eine Glättung des Produktionspro- 
gramms angesehen werden, die eine Erhöhung der Kapazitätsausla- 
stung ermöglicht. 

Die folgende Abbildung skizziert den Planungsablauf des hier zu- 
grunde gelegten Konzeptes [Hintz 1987, S. 126]. 




Abb. 1: Planungsablauf 



Wie schon erwähnt, soll die Terminierung mit Hilfe von linearem 
Programmieren durchgeführt werden. Die folgenden Restriktionen 
sind im wesentlichen zu berücksichtigen: 

1. Werkstücke können nur bearbeitet werden, wenn ihre Bearbeitung 
in früheren Produktionsstufen abgeschlossen ist. 

2. Fertigstellungstermine sind einzuhalten, um die Abläufe auf 
folgenden Fertigungsstufen nicht zu verzögern. 

3. Die Kapazitäten der Komponenten der FMS dürfen nicht über- 
schritten werden. Da sie teilweise substituierbar sind, ist 
eine entsprechende Gruppierung vorzunehmen. 
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4. Es existiert nur eine beschränkte Anzahl von Paletten. 

Die folgenden Variablen und Symbole sollen verwendet werden: 

Xj^: Anzahl der von Werkstück Typ j in Planungsperiode t 

zu bearbeitenden Teile, j = 1, ... n; t = 1, . . . , T. 

bj^: komulierter Bedarf an Teil j bis Periode t, 

j = 1, . . n; t = 1, . . . , T. 

Vj|.: ab Periode t verfügbare Teileanzahl von Typ j, 

j = 1, . . n; t = 1, . . . , T. 

Pjjj : Bearbeitungszeit für Arbeitsvorgang h an Teil j , 

h = 1, . . , H; j = 1, . . n. 

aavj^j: Häufigkeit des Arbeitsvorgangs h für ein Teil vom 

Typ j, h = 1, H; j = 1, . . n. 

1 1 , Maschine i kann Arbeitsvorgang h durchführen 
0 , sonst . 

az^: Arbeitszeit in Periode t, t=*l, ..., T. 

amj^: Anzahl Maschinen vom Typ i, i = l, .../ m. 

1, Arbeitsvorgang h ist mit Spannvorrichtung k 
avShk = durchzuführen 
0 , sonst . 

asj^: Anzahl Spannvorrichtungen vom Typ k, k=l, ..., z. 

korr^: Korrekturfaktor zum Ausgleich von ablauf bedingten 

Schwankungen in Periode t, t=l, ..., T. 

Damit können die Restriktionen wie folgt dargestellt werden: 
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(1) Verfügbarkeit der Werkstücke 



( 2 ) 

(3) 



t 

S Xjs ^ Vjt j = 1, n; t = 

S=1 

Fertigste llungstermine der Werkstücke 
t 

S Xjg > bjt j = 1, n; t = 

s=l 

Kapazität der Maschinen 
n m 

2 pj^j aaVj^ < 2 az^ korr^ ^®it 

h = , 



1/ • • • / T 



i f • • • f T 



aviQhi 

H t = 1, . 



(4) Kapazität der Spann Vorrichtungen 

n z 

S Phj aaVhj Xjt < 2 az^ korr^ asj^^ 

J =1 1=1 

h = 1, H t = 1, 



T 



r T 



Hierzu kommen selbstverständlich die entsprechenden Nichtnegativi- 
tät sbedingungen . 

Als Zielfunktion sind grundsätzlich sowohl eine Maximierung der 
Deckungsbeiträge als auch eine Maximierung der Kapazitätsausla- 
stung oder eine Minimierung der Lagerkosten und schließlich eine 
Maximierung der Termineinhaltung denkbar. Kosten- bzw. deckungs- 
beitragsbezogene Zielfunktionen leiden meist an einem Mangel ad- 
äquater Information. Deswegen werden oft terminbezogene Ziele vor- 
gezogen. Die Termineinhaltung ist zwar formal in den Restriktionen 
bereits sicher gestellt. Es besteht jedoch die Gefahr, daß keine 
zulässige Lösung gefunden werden kann, wenn einzelne Termine zu 
knapp gesetzt werden. Daher ist es zweckmäßig, sowohl ein Vor zie- 
hen von noch nicht freigegebenen Aufträgen als auch einen Verzug 
der Fertigstellungstermine grundsätzlich zuzulassen. Dann besteht 
das Ziel der simultanen Terminplanung für flexible Fertigungssy- 
steme darin, die vorgegebenen Termine möglichst gut einzuhalten. 

In der Praxis sind oft Restriktionen nicht so starr, wie es das 
Modell zu suggerieren scheint. Es kann also sinnvoll sein, zu 
überprüfen, wie restriktiv die formulierten Nebenbedingungen 
tatsächlich sind. Dabei stellt man fest, daß die Termine von den 
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jeweiligen Bereichsleitern häufig sehr knapp gesetzt werden, um in 
der eigenen Abteilung eine möglichst reibungslose Durchführung der 
Produktion zu ermöglichen. Darüber hinaus besteht durch Überstun- 
den, überlappende Fertigung bzw. Lossplittung in den vor- bzw. 
nachgelagerten Fertigungsbereichen die Möglichkeit, auf einen Teil 
der Werkstücke bereits früher zuzugreifen bzw. einen Teil von 
einem Auftrag erst später fertigzustellen, ohne daß der Produk- 
tionsablauf insgesamt gestört wird. Eine analoge Aussage kann über 
den Stellenwert der Termineinhaltung im Rahmen einer marktgerech- 
ten Lieferbereitschaft gemacht werden. So ist es nicht gewiß, daß 
beispielsweise eine geringe Senkung des Servicegrades - also des 
Verhältnisses von befriedigtem zu angefordertem Bedarf - zu nega- 
tiven Kundenreaktionen führt. 

Um diese Situation angemessen zu modellieren, werden die entspre- 
chenden Restriktionen als "flexible** oder unscharfe Restriktionen 
im Sinne des unscharfen linearen Programmierens [siehe Zimmermann 
1987a] aufgefaßt. Dazu Hintz [1987, S. 137]: . 

**Im folgenden wird der Gedankengang, wie eine Restriktion zur un- 
scharfen Restriktion modifiziert wird, am Beispiel der Fertigstel- 
lungstermine des LP-Modells zur Terminplanung dargestellt. Dazu 
werden zunächst die folgenden Entscheidungsvariablen zusätzlich 
definiert: 

fXj^: Fehlmenge von Werkstücktyp j bis zur Periode t, 

^ ~ 1, ..., n/ t “ 1, ..., T. 

Wegen der Zulassung von Fehlmengen müssen die Restriktionen der 
Gruppe (2) modifiziert werden: 



t 



(2.1) 


S Xjs + fXfjt ^ bjt 

S=1 


V 


j 


V 


t 


(2.2) 


fXjt ^ 0 


V 


j 


V 


t 


(2.3) 




V 


j 


V 


t 



Restriktion (2.1) stellt sicher, daß die bis zur Periode t nicht 
einplanbaren Teile vom Typ j in der Variablen fXj^ erfaßt werden. 
(2.2) entspricht der Nichtnegativitätsbedingung. In Nebenbedingung 
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(2.3) ist gefordert, daß möglichst keine Fehlmengen eingeplant 
werden. Das Symbol bedeutet, daß die Restriktion nicht mehr 

exakt, sondern nur noch möglichst gut einzuhalten ist. Wird die 
exakte Einhaltung gefordert ("<”)/ so besteht kein Unterschied zu 
Restriktion (2) . 

Die Restriktion (2.3) ist im folgenden zu präzisieren. 

Sei mit 

fmj^ die maximal erlaubte Fehlmenge von Werkstücktyp j bis 
zur Planungsperiode t 
bezeichnet. 

Damit kann für die Restriktion (2.3) eine (stückweise lineare) Zu- 
gehörigkeitsfunktion definiert werden: 



Mjt(x) = 



1, 


fXjt = 0 


f“jt 


0 < fXjt < fmjt 


0, 


flOjt ^ 



Unter Benutzung des in Zimmermann [1987a] erläuterten Ansatzes 
kann nun für Restriktion (2) folgende äquivalente scharfe Darstel- 
lung gewählt werden: 



max A 

t 

s-d. Xjg + fXjt ^ bj^. 

fmjt*^ + ^ 

A> 0. ” 



V j V t 

V j V t 



Für die anderen als flexibel anzusehenden Nebenbedingungen wird 
entsprechend vorgegangen. Das Gesamtmodell wird dann zweckmäßiger- 
weise rollierend angewandt, wobei sich seine Struktur offensicht- 
lich nicht ändert. 



B. Einlastung und Naschinenbelegung. 

Für Einlastung und Maschinenbelegung soll der gleiche prinzipielle 
Ansatz verwendet werden: die Steuerung durch Prioritätsregeln. Ge- 
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genüber dem klassischen Prioritätsregelprinzip bestehen jedoch 
zwei wichtige Unterschiede: 

1. Es werden mehrere lokale Regeln hierarchisch zu jeweils einer 
globaleren Regel aggregiert. 

2. Regeln werden nicht im schlangentheoretischen Sinne interpre- 
tiert, sondern als Darstellung von Expertenwissen. 

Hieraus ergeben sich zwei Konsequenzen: 

a) Durch die kontrollierbare hierarchische Aggregation kann die 
dem Fertigungssteuerungsproblem innewohnende Mehr z ielproblema- 
tik angemessen modelliert und gelöst werden. 

b) Da Expertenwissen gewöhnlich in linguistischer Form vor liegt, 
muß eine Modell-Sprache gewählt werden, die eine angemessene 
Modellierung und Verarbeitung linguistischer Information zu- 
läßt. 

Das prinzipielle Vorgehen soll an der Einlastungsentscheidung ver- 
deutlicht werden: 

Man nehme an, daß eine Menge von Produkten (Teilen) zur Einlastung 
in das FMS bereitsteht. Für deren Eignung zur Einlastung soll nun 
ein Maß (eine Priorität) berechnet werden, aufgrund dessen das 
Teil mit der höchsten Eignung ermittelt oder aber eine Menge der 
am meisten geeigneten Teile bestimmt werden kann. 

Für die Einlastung sei nun eine Kriterienhierarchie angenommen, 
wie sie in folgender Abbildung gezeigt wird: 
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Abb. 2: Mögliche Kriterienhierarchie zur Einlastung 



Die Aggregation zweier Subkriterien (hier z.B, «Schlupf zeit” und 

"Wartezeit”) zu einem Kriterium (hier also z.B. "terminbezogene 

Kriterien”) kann nun auch durch eine Menge von "Produktionsregeln” 

beschrieben werden. Eine solche Regelmenge könnte z.B, lauten: 

1, Wenn die Wartezeit lang und die Schlupf zeit sehr kurz ist, dann 
ist terminbezogenes Kriterium wichtig (l) . 

2, Wenn die Wartezeit mittel und die Schlupf zeit kritisch kurz 
ist, dann ist terminbezogenes Kriterium wichtig (0,8). 

3, Wenn die Wartezeit kurz und die Schlupf zeit kritisch kurz ist, 
dann ist terminbezogenes Kriterium wichtig (0,6). 

4. Wenn die Wartezeit lang und die Schlupf zeit kurz ist, dann ist 
terminbezogenes Kriterium wichtig (0,5). 

5. Wenn die Wartezeit mittel und die Schlupf zeit kurz ist, dann 
ist terminbezogenes Kriterium wichtig (0,2). 

6. Wenn die Wartezeit mittel und die Schlupf zeit kurz ist, dann 
ist terminbezogenes Kriterium unwichtig (0,7). 
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Die bei den jeweiligen Regeln in Klammern befindlichen Zahlen ge- 
ben einen "Einsichtigskeitsgrad” , "Plausibilitätsgrad” o.ä. für 
die jeweilige Regel an, der vom Experten zu erfragen ist. Zwei 
Fragen stellen sich dann: 

1. Wie werden die Regelinhalte quantitativ modelliert? 

2. Wie werden die Regeln aggregiert (verarbeitet), um schließlich 
zu einem Prioritätsmaß des Wurzelknotens der Hierarchie zu ge- 
langen? 

Z-M is 

Hierzu werden sogenannte "linguistische Variable" benutzt [siehe 
z.B. Zimmermann 1987b, S. 237]. Dies sind Variable, die nicht nu- 
merische, sondern linguistische Werte (sogenannte "Terme") anneh- 
men können, die dann wiederum jeweils als unscharfe Mengen 
[Zimmermann 1987a] modelliert werden können. 

Für die linguistische Variable "Schlupfzeit" könnte die Menge der 
Terme z.B. sein: {kritisch, kurz, ausreichend}. Verwendet man tra- 
pezförmige Zugehörigkeitsfunktionen, wie in der nächsten Abbildung 
gezeigt, so könnte die Definition der Terme als unscharfe Menge, 
wie in Abb. 4 gezeigt, aussehen. 











1 


/ 




\ 




a 1 


3 ( 


; d X 



Abb. 3: Stückweise lineare Zugehörigkeitsfunktion 
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Wertebereich 


Parameter 

a b c d 






Schlupf zeit 


kritisch 

kurz 

ausreichend 


-00 -oo 3.0 4.5 

3.0 4.5 6.0 8.0 

6.0 8.0 eo “> 



Abb. 4: Definition der linguistischen Variable "Schlupf zeit eines 
Auftrags” 




Abb. 5: Zugehörigkeitsfunktionen der linguistischen Variable 
"Schlupfzeit eines Auftrags” 



Bei allen hier verwendeten linguistischen Variablen definiert die 
Zugehörigkeitsfunktion /x den Zugehörigkeitsgrad von Elementen der 
"Basisvariablen” (in den Abbildungen z.B. "Schlupf zeit” in Tagen) 
zu dem jeweiligen Term der Basisvariablen. 

2H- 2? 

Hier kann man sich des sogenannten approximativen Schließens 
(approximate reasoning) [siehe z.B. Zimmermann 1987b] bedienen, 
einer Art des Schließens, die es erlaubt, in den Regeln enthaltene 
unscharfe Komponenten adäquat zu berücksichtigen. Ohne an dieser 
Stelle ins Detail zu gehen, kann man die Anwendung des 
approximativen Schließens auf die Einlastung, wie in Abb. 6 
gezeigt , beschreiben . 
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Wähle Werkstück mit höchstem 
Zugehörigkeitsgrad (Priorität) 
zur Einlastung 



4 




Abb. 6: Einlastung mit approximativem Schließen 
Die Maschinenbelegung erfolgt in analoger Weise. 
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C: Simulation der Güte des beschriebenen Systems 

Zur Bestimmung der Leistungsfähigkeit des skizzierten Systems wur- 
den Daten generiert, die der Struktur realer FMS entsprechen. Si- 
mulativ wurde das System dann mit Systemen verglichen, die die 
Terminierung nicht mit LP durchführen und die für die Steuerung 
Prioritätsregeln benutzen. Als beste Prioritätsregel erwies sich 
hierbei die Regel "Covert**, die Bearbeitungs- und Schlupf zeit kom- 
biniert. 

Bewertet wurden drei Zielsetzungen: Wartezeit, Termintreue, Ma- 
schinenauslastung. Vergleicht man bezüglich dieser drei Kriterien 
ein System, bei dem mit unscharfem LP terminiert und mit approxi- 
mativem Schließen gesteuert wurde (LP/EM) , mit einem System, das 
phne LP terminierte, für die Einlastung die Prioritätsregel "Zahl 
der bereits eingelasteten Stücke eines Loses dividiert durch ge- 
samte Losgröße" (Q) und zur Steuerung die Regel "Covert" benutzte 
(C) , so ergeben sich folgende Ergebnisse [Hintz/ Zimmermann 1989, 
S. 332]: 



System 


Wartezeit 


Termintreue 


Kapazitätsauslastung 




(Min. ) 


(%) 


(%) 


LP/ EM 


2884 


97 


80 


-/QC 


3369 


28 


79 



Die beachtlichen guten Ergebnisse des vorgeschlagenen Systems sind 
offensichtlich. Es soll darüber hinaus noch einmal darauf hinge- 
wiesen werden, daß die Mehr Zielproblematik durch Kontrolle des Ag- 
gregationsverfahrens adäquat gelöst werden kann. 

Der rechnerische Aufwand ist durchaus vertretbar: Für ein Problem 
mit 200 Werkstücken, 10 Maschinen und 9 Zeitperioden Planungshori- 
zont ergab sich ein unscharfes LP mit ca. 500 Variablen und 800 
Restriktionen (Matrixdichte = 1,1 %) . Die Rechenzeit mit APEX IV 
auf einer Cyber 175 betrug 22 CPU sec. Für den Steuerungsteil 
liegt die Bewertung der Werkstücke auf einer VAX im 10“^ CPU Se- 
kundenbereich, auf einem IBM-AT mit Intel 8088 Prozessor und Intel 
8087 Co-Prozessor ca. 1,4 SPU-sec. 
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5, Ausblick 



Es wurde skizziert, warum in den sechziger und siebziger Jahren 
das bestehenden Potential leistungsfähiger OR-Verfahren auf einem 
so wichtigen Gebiet wie dem der Produktionsplanung und -Steuerung 
nur zu einem sehr geringen Maße zum Tragen gebracht werden konnte. 
Die Rahmenbedingungen für den Einsatz dieser Methoden sind jetzt 
sehr viel günstiger als damals. Trotzdem besteht die Gefahr, daß 
durch die Fokussierung auf Expertensystemen der Wert und die An- 
wendbarkeit von leistungsfähigen OR-Verfahren wieder übersehen 
wird. Um dies zu verhindern, wird eine Symbiose von ES-Technologie 
und OR- Ansätzen vorgeschlagen, durch die die Vorteile beider Werk- 
zeuge genutzt und ihre Schwächen weitgehend vermieden werden kann. 
Es ist zu hoffen, daß auf diese Weise bemerkenswerte Verbesserun- 
gen der Entscheidungsgüte auf dem Gebiet der Produktionsplanung 
und -Steuerung erzielt werden können. 
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0 Einleitung 

Die Fertigungssteuerung nimmt zunehmend die zentrale Stellung im Unternehmen ein und 
stellt das eigentliche Herz des Produktionsbetriebes dar. Die Zielsetzungen einer hohen 
Termintreue, kurzen Durchlaufzeit und bestandsarmen Produktion werden mit 
konventionellen Methoden nicht effektiv unterstützt. Zur Überwindung dieser Schwächen 
müssen neue Konzepte entwickelt werden, wobei Methoden der Künstlichen Intelligenz (Kl) 
verstärkt an Bedeutung gewinnen. 

In /ALBAYRAK90a/ wurden die Probleme konventioneller Methoden zur Lösung der 
Aufgaben in der Fertigung und die Vorteile des Einsatzes Kl-basierter Methoden ausführlich 
beschrieben. 

Die für die Durchsetzung des Fertigungsprogrammes notwendigen Teilaufgaben 
(Reihenfolge- und Feinplanung, Konflikterkennung, Konsistenzerhaltung, Störungs- 
behandlung) sind in /ALBAYRAK90b/ beschrieben und es wird gezeigt, daß diese 
Teilaufgaben eine Komplexität aufweisen, die es nahezu verbietet, auf konventionelle 
Lösungsansätze zurückzugreifen. An dieser Stelle soll die Komplexität am Beispiel der 
Feinplanung (Maschinenbeiegungsplanung), die in der englischsprachigen Literatur als 
"scheduling" bekannt ist, aufgezeigt werden. Zu dieser Problemstellung schreibt Fox; 

’[...} in a single factory having 85 ordere, 10 operations, and only one substitutable 
maschine, we could create over 10^^^ alternative schedules. Therefore, whiie this 



'Diese Arbeit wird von Digital Equipment GmbH und KRONE AG, Berlin, finanziell unterstützt. 
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Style of search is theoretically interesting, it is impractical because too many 
alternatives must be considered. Search must be smarter; in fact, search must be 
structured such that the search space is reduced from lO^^O to something much 
smaller and more manageable.7FOX90/ 

Darüber hinaus ist das für die Lösung der einzelnen Teilaufgaben notwendige Wissen auf 
verschiedene Personen verteilt. 

Die Methoden der Kl sind geeignet, das oftmals in verschiedenen Experten (Arbeitsplaner, 
Produktionssteuerer, Werkstattmeister, Vorarbeiter, Einrichter, etc.) verkörperte Wissen in 
einer Wissensbasis abzubilden und im Verlauf eines Problemlösungsprozesses auf dieses 
Wissen zurückzugreifen. Das zur Feinplanung, Diagnose und Reaktion auf Störungen 
notwendige Wissen kann für jeden Entscheidungsträger separat in einem Expertensystem 
operationalisiert werden. Die Integration der einzelnen Expertensysteme in ein 
unternehmensweites CIM-Konzept ist für zukunftsorientierte Lösungsansätze unabdingbar, 
wenn das "I" in CIM richtig verstanden wird. Weiterhin ist auch die Kooperation zwischen 
Expertensystemen zur Realisierung der oben genannten Ziele im Kontext eines 
wissensbasierten Systems in der Fertigung ein unverzichtbares Erfordernis. 

Bei der Lösung der Aufgaben in der Fertigung findet eine intensive und zielgerichtete 
Kooperation zwischen den am Problemlösungsprozeß beteiligten Agenten (Experten) statt. 
Die Modellierung dieser Vorgehensweise in einem Einagentensystem (Expertensystem) ist 
nicht nur äußerst schwierig, sondern auch unzweckmäßig. Eine adäquate Modellierung des 
Problemlöseprozesses in der Fertigung erfordert ein Mehragentensystem, bei dem auch die 
Kommunikation zwischen den Agenten angemessen nachgebildet wird. 

Das erzwingt die Analyse von Konzepten aus dem Bereich des verteilten Problemlösens bzw. 
verteilter wissensbasierter Systeme (distributed artificial Intelligence, DAI) und deren 
Umsetzung innerhalb zukunftsorientierter Fertigungssteuerungskonzepte. 

In diesem Papier werden Lösungsansätze für diese Problemstellung aufgezeigt. In Kapitel 1 
wird der Begriff einer verteilten Problemlösung erläutert und die daraus resultierenden 
Vorteile beschrieben. In Kapitel 2 wird das Blackboardmodell als Metapher einer 
kooperierenden Problemlösung vorgestellt. Im 3. Kapitel wird ein am Fachgebiet 
Systemanalyse und EDV der Technischen Universität Berlin entwickelter Ansatz zur Lösung 
von Problemen in der Fertigung vorgestellt. Es handelt sich um ein Konzept für einen 
verteilten wissensbasierten Fertigungsleitstand auf der Basis einer Blackboard Architektur, 
realisiert unter Verwendung des Tools "Generic Blackboard System” (GBB). In Kapitel 4 wird 
die Teilkomponente "Störungsbehandlung" im Rahmen einer Falistudie dargestelit. 
Anschließend erfolgt in Kapitel 5 eine kurze Zusammenfassung. 
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1 Verteiltes Problemlösen 



1.1 Was heißt "verteiltes Problemlösen"? 

Eine in der Künstlichen Intelligenz (Kl) beliebte Metapher für eine verteilte Problemlösung ist 
eine Gruppe menschlicher Experten, die in Zusammenarbeit ein komplexes Problem lösen. 
Dabei wird angenommen, daß jeder der Experten ein bestimmtes Teilproblem zu bewältigen 
hat. Während der Bearbeitung eines Teilproblems kann die Einschaltung anderer Experten 
oder ein Informationsaustausch innerhalb der Gruppe einer Lösungsfindung dienlich sein. 

Im ersten Fall wird eine weitere Problemzerlegung vorgenommen und die sich ergebenden 
Unterprobleme an andere Experten delegiert, sofern diese ihre Fähigkeit und Bereitschaft 
signalisieren, die ihnen beschriebene Aufgabe zu übernehmen. Im zweiten Fall soll durch 
Weitergabe von partiellen Lösungen eines Teilproblems die Lösung verwandter, evtl, 
voneinander abhängiger Teilprobleme ermöglicht oder beschleunigt werden. 

Durch die Synthese der verschiedenen Teillösungen wird eine Lösung des komplexen 
Problems erreicht. 

Keiner der Experten hat die vollständige Kontrolle über alle anderen Experten. Dies schließt 
nicht aus, daß einer als Verantwortlicher für die Gesamtlösung fungiert und Ergebnisse an die 
Außenwelt weitergibt. 

Ein Beispiel für verteiltes Problemlösen ist der Entwurf und Bau eines Hauses, der von 
mehreren Experten oder auch Expertengruppen in Kooperation bewerkstelligt wird 
/DURFEE89/. Es gibt Spezialisten für die Statik, die für die Stabilität des Bauwerks 
verantwortlich sind, andere für die Raumaufteilung, Plazierung von Fenstern, Türen, etc., 
desweiteren Maurer, Installateure, Elektriker usw. Die verschiedenen Experten benutzen zum 
Teil unterschiedliche Hilfsmittel zur Erledigung ihrer Aufgaben. Sie müssen kooperieren, da 
keiner das Gesamtproblem, den Bau eines Hauses, alleine zu lösen vermag. Zur Lösung 
bestimmter Teilaufgaben müssen Teillösungen weitergegeben werden, beispielsweise die 
Raumplanung an die Installateure und Elektriker, die die Wasser- und Elektroinstallation 
vornehmen müssen. Weitere Arten der Kommunikation sind die Delegation bestimmter Teil- 
aufgaben an Vertragsnehmer (z.B. die Auswahl eines Bauunternehmers, eines Elektrikers,...), 
die Kontrolle der Realisierung eines Entwurfs (z.B. der Statik, Raumorte und -größen etc.) und 
viele andere mehr. 

Verteiltes Problemlösen kann abstrakt als 'kooperative Lösung eines Problems durch 
dezentralisierte lose gekoppelte Wissensquellen’ /SMITH/DAVIS 81/ bezeichnet werden. Im 
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Falle der kooperierenden Experten sind die Wissensquellen menschliche Spezialisten; 
übertragen auf die Kl können Wissensquellen Prozeduren, Regelmengen, etc., auf 
verschiedene Prozessoren verteilt sein, wobei Prozessoren auch softwaremäßig realisiert 
sein können. 

Die Wissensquellen kooperieren miteinander, da keine allein in der Lage ist, das 
Gesamtproblem zu lösen. Erst durch die Aufteilung des Problems in spezielle Teilprobleme 
und den wechselseitigen Austausch von Ergebnissen kann die globale Aufgabenstellung 
gelöst werden. 

Dezentralisiert heißt, daß sowohl Kontrolle als auch Daten logisch oder sogar räumlich verteilt 
sind. 

Lose gekoppelt sind die Wissensquellen, wenn sie einen größeren Anteil ihrer Aktivität zur 
Lösung des ihnen zugewiesenen Teilproblems als für die Kommunikation mit anderen 
Wissensquellen verwenden. 

1.2 Warum ein Problem verteilt lösen? 

Eine verteilte Problemlösung bietet mehrere Vorteile: 

- Effizienz: "Advances in hardware tachnology for processor construction and 
interprocessor Communications make it possible to connect together large numbers of 
powerfui, yet inexpensive, Processing units that execute asynchronously. Interconnected 
processors can be a cost-effective way to provide the computadonal cycles required by 
AI applications. " /DU RFEE89/ 

Bei einer Realisierung mit jeweils einem Prozessor pro Wissensquelle können Teilsysteme 
parallel operieren. Gerade im Hinbiick auf die zunehmende Verbreitung von 
Mehrprozessorsystemen eröffnet die verteilte Modellierung von Problemlösungen 
Möglichkeiten, das Leistungspotential dieser Systeme im vollen Umfang zu nutzen. Das 
könnte beim verteilten Problemlösen bedeuten, daß jedem Spezialist ein eigener Prozessor 
zugeordnet würde und die Spezialisten wirklich nebenläufig arbeiten. Desweiteren steigen 
durch die Verwendung innovativer Technologien (z.B. B-ISDNi) die Bandbreite und 
Libertragungsgeschwindigkeiten lokaler und flächendeckender Netzwerke in erheblichem 
Maße, so daß auch die räumliche Verteilung einer Problemlösung begünstigt wird. 

- Redundanz: Es ist möglich, daß mehrere Wissensquellen gemeinsam gleiche oder 
überlappende Teilprobleme bearbeiten. 



i Breitband-ISDN 
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"Distributed AI Systems may be more reliable than are centralized Systems because they 
provide redundancy, cross-checking, and triangulation of results" /MASON88/ 

Dadurch kann zum einen die Zuveriässigkeit des Gesamtsystems erhöht werden, da auch bei 
Ausfall einer Komponente eine Lösungsfindung mögiich ist. Zum anderen kann so eine 
bessere Lösung auch eines Teilproblems entstehen, da verschiedene Lösungsmethoden und 
Perspektiven integrativ evaluiert werden können. 

Hierbei gibt es allerdings zwei wesentliche Schwierigkeiten: 

1 . Wie kann man verhindern, daß doppeite Arbeit geleistet wird? 

2. Wie kann man gegenseitige Beeinfiussung vermeiden? 

Diese beiden Fragen sind kennzeichnend für eine Problemiösung mit redundantem Wissen. 
Sie machen deutlich, daß Redundanz und Effizienz miteinander in Konflikt stehen. 

- Modularität, Wiederverwendbarkeit : “The ability to structure a complex Problem 
into relatively self-contained processIng modules leads to Systems that are easier to 
build, debug, and maintain and that are more resilient to Software and hardware errors 
than a single, monolithic module." /DURFEE89/ 

Durch die Zerlegung in N Subsysteme wird die Komplexität um signifikant mehr als einen 
Faktor N reduziert. Das Gesamtsystem ist leichter zu entwickeln, zu testen und zu warten. 
Weiterhin lassen sich kleinere, modulare System komponenten in verschiedenen 
Anwendungskontexten wiederverwenden. 

ln vielen Fällen legt schon der Problemcharakter eine verteilte Lösung nahe. Besonders, 
wenn das Problem durch seine Teilprobleme und deren Interaktion formuliert ist, erscheint 
der verteilte Ansatz unmittelbar einleuchtend und adäquat. Bei einer räumlichen Verteilung 
komplexer und zeitkritischer Systemkomponenten, wie beispielsweise in einer 
unternehmensweiten, mehrere Fabrikationsstätten einbeziehenden Fertigungssteuerung und 
-Überwachung ist der verteilte Ansatz nahezu erzwungen, da sonst probleminhärente iokale 
Echtzeitanforderungen nicht erfüllt werden können (siehe /PARUNAK87/). 

Bei der Entwicklung von Expertensystemen kommt ein weiterer Aspekt hinzu: genereil 
existieren für eine Domäne mehrere Experten mit überlappender Expertise, die kooperierend 
erheblich bessere Ergebnisse erzielen als jeder Experte allein. Also bietet es sich an. Wissen 
von mehreren Spezialisten zu akquirieren und in eine verteilte Systemarchitektur abzubilden. 

Den oben genannten Vorteilen einer verteilten Problemlösung stehen allerdings auch einige 
Schwierigkeiten gegenüber. An dieser Stelle sind einige Probleme aufgeführt, die beim 
verteilten Problemlösen entstehen können und im allgemeinen mit dem Begriff Kontroiie 
gekennzeichnet werden. 
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In allen Phasen, die beim verteilten Problemlösen zu durchlaufen sind, können auch 
Schwierigkeiten auftreten. Es kann schwierig sein, ein Problem zu zerlegen und den 
geeigneten Agenten für die Lösung einer Teilaufgabe zu finden. Es kann auch verkommen, 
daß doppelte Arbeit geleistet wird und die Agenten, die einzelne Teilprobleme bearbeiten, 
sich gegenseitig behindern. Das kann dazu führen, daß Schwierigkeiten bei der 
abschließenden Lösungssynthese auftreten. 

Trotz der aufgeführten Schwierigkeiten die beim verteilten Problemlösen auftreten können, 
überwiegen die Vorteile, die aus diesem Ansatz resultieren. 

2 Das Blackboardmodell und das Werkzeug GBB 



2.1 Das Blackboardmodell 

Die Idee des Blackboard Modells wird von Newell folgendermaßen beschrieben: 

"Metaphorically we can think of a set of workers, all looking at the same blackboard: 
each Is able to read everything that Is on it, and to judge when he has some things 
worthwhile to add to it... (Newell, 1962)" /NII86a/. 

Die Grundlage des Blackboardmodells ist offensichtlich die Situation des kooperativen 
menschlichen Problemlösens gewesen (Abb. 1). Verschiedene Spezalisten verfolgen 
gemeinsam das Ziel, ein komplexes Problem zu lösen. Dabei haben die Spezialisten Wissen 
über die Bearbeitung von Teilproblemen, aus denen sich das Gesamtproblem 
zusammensetzt. 

Nachfolgend sollen einige Charakteristika des Blackboardmodells aufgezählt werden: 

• Der Zustand der Problemlösung ist jederzeit allen Spezialisten bekannt. Dadurch ist 
prinzipiell jedem Spezialisten die Möglichkeit gegeben, aktiv und selbständig in den 
Problemlöseprozeß einzugreifen. 

• Verschiedene Spezialisten, von denen jeder allein nicht in der Lage wäre, ein 
komplexes Problem zu lösen, können ihr Wissen über Teilgebiete des Problems 
einbringen, um eine inkrementeile Gesamtproblemlösung zu erreichen. 

• In vielen Fällen können Teilprobleme gleichzeitig durch mehrere Spezialisten gelöst 
werden. 



Lösen mehrere Spezialisten dasselbe Teilproblem, so können Fehler aufgedeckt und 
alternative Lösungen verfolgt werden ( hierbei können die gleichen Schwierigkeiten 
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entstehen, wie sie in Kap. 1 unter dem Stichwort Redundanz bereits genannt wurden). 




Abb. 1 : Das Blackboard-Problemlösemodell (aus /Winston87/) 



Um eine sinnvolle, in der Regel effiziente Problemlösung zu erzielen, müssen die 
Spezialisten eine bestimmte Vorgehenweise bei der Problemlösung verfolgen. 

Diese kann, wie auch häufig bei menschlichen Teams üblich, durch einen Leiter bestimmt 
werden. In den Problemlösungsmodellen wird diese Aufgabe als Kontrolle bezeichnet. Die 
konkrete Vorgehenweise, mit der die Spezialisten das Problem lösen, nennt man Strategie. 

Das erste auf diesem Modell basierende System ging aus dem HEARSAY-Il-Projekt hervor, 
dessen Ziel es war, gesprochene Sprache zu erkennen. Seitdem wurden mehrere auf 
diesem Modell basierende Systeme entwickelt. Abbildung 2 zeigt die Evolution der 
Blackboardsysteme. 
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ungefährer 

Zeitraum 




Abb. 2: Die Evolution der Blackboardsysteme (aus /ENGELMORE88/) 



2.2 Das Werkzeug GBB 

GBB wurde am Department of Computer and Information Science der University of 
Massachusetts at Amherst entwickelt. 

In /JOHNSON88/ werden zwei wesentliche Zieie von GBB genannt: das flexible und schnelle 
Erstellen von Blackboard-Anwendungen und eine effiziente Laufzeit solcher Anwendungen. 

GBB umfasst zwei getrennte Teilsysteme: einen Blackboard Datenbasis-Compiler und einen 
Satz von generischen Kontroll-Shells. Dies erlaubt eine von der jeweiligen Applikation 
unabhängige Implementation von Kontrollstrategien, außerdem ermöglicht es eine Änderung 
der Datenbasis ohne Beeinflussung der Kontroll-Shell und umgekehrt. 

Der Datenbasis-Compiler besteht seinerseits aus zwei Spezifikationssprachen: eine für die 
Definition von Blackboards und Blackboard-Objekten, die andere für die effiziente 
Spezifizierung der Speicherstruktur. Dies erlaubt es, einen Entwurf von Blackboard-basierten 
Applikationen in zwei Phasen aufzuteilen: Implementierung der Applikation zum einen, 
Auswahlen geeigneter Speicherstrategien zum anderen. 

Mit Hilfe der Konstrukte von GBB lassen sich Kontroll-Shells zur Realisierung der Kontroiie 
implementieren. GBB stellt zwei solcher Kontroll-Shells zur Verfügung: die Simpie Control 
Shell und GBB1 . Diese Kontroll Shells ermöglichen das Definieren von Knowledge Sources 
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(Wissensquellen) sowie deren Kontrolle. Mit dem Simple Control Shell soll beispielhaft 
aufgezeigt werden, wie eine Kontroll-Shell mit Hilfe von GBB implementiert werden kann; sie 
ist dementsprechend nicht für komplexe Anwendungen geeignet /JOHNSON88/. Für 
komplexere Anwendungen steht die Kontroll Shell GBB1 zur Verfügung, welche auf dem 
Kontrollmodell BB1 /HAYES-ROTH85/ basiert. Das Werkzeug GBB ist in /JOHNSON88/ 
ausführlich beschrieben. 



3 Ein verteilter Lösungansatz zur Problemlösung in der 
Werkstattsteuerung 

Im Rahmen eines Forschungsprojektes wurde an der Technischen Universität Berlin 
innerhalb des Fachgebietes Systemanalyse und EDV, unter der Leitung von Prof. Dr. H. 
Krallmann ein Lösungsansatz entwickelt, der den Anforderungen, die an eine zeitgemäße 
Fertigungssteuerung gestellt werden, gerecht wird. 

Für die Lösung jedes der in der Fertigung vorhandenen Teilprobleme wird eine Knowledge 
Source (Expertensystem) realisiert. Der Problemlöseprozeß ist, wie gefordert, kooperativ 
modelliert; die Kooperation wird über Blackboards verwirklicht. 

Der Lösungsansatz besteht aus zwei Teilen: 

• Der Benutzerschnittstelle; sie erlaubt das Planen "per Hand” und stellt 
Auskunftsfunktionen zur Verfügung. 

• Einem wissensbasierten Ansatz zur Durchsetzung des Fertigungsprogrammes, wobei 
für die Lösung der einzelnen Teilaufgaben jeweils eine Knowledge Source (KS) 
realisiert wird. 

Beide Teile verwenden eine gemeinsame Wissenbasis. 

In Abbildung 3 ist die Architektur des auf dem Blackboardmodell basierenden 
wissensbasierten Leitstandes dargestellt. Im folgenden werden die einzelnen Komponenten 
des Systems kurz erläutert. 

3.1 Werkstattmodellierer 

Der Werkstattmodellierer stellt auf der Domänen-Blackboard ständig den aktuellen Zustand 
der Werkstatt dar, die sog. aktuelle Werkstatt. 

Hierzu erhält diese Komponente von der Überwachung (BDE) die Daten über Kapazitäten, 
Maschinen, Personal, Materialien und andere Ressourcen (z.B. Werkzeuge) und aktualisiert 
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das Modell der Werkstatt diesen Daten entsprechend auf der Domänen-Blackboard. 

Sie sorgt dafür, daß den anderen Komponenten aktuelle und korrekte Daten bereitgestellt 
werden. 




Ltgcntft 



:^grnlt±u 



Abb. 3: Systemarchitektur des wissensbasierten Fertigungsleitstandes 



3.2 Konsistenzprüfung 

Die Komponente zur Konsistenzprüfung besteht aus zwei Knowledge-Sources. Diese dienen 
zur 

• Erhaltung der Konsistenz der Belegungspläne, die von der Planungstomponente oder 
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durch den Benutzer erzeugt wurden; 

• Aufdeckung von Konflikten zwischen Soll- und Ist-Zustand in der Werkstatt. Die hierzu 
notwendigen Daten werden vom Werkstattmodellierer übermittelt. Diese Knowledge- 
Source besteht ihrerseits wiederum aus zwei Komponenten: 

• eine Teilkomponente dient der Aktualisierung der Planungsdatenbasis (Status von 
Ressourcen, Arbeitsgängen und zugehörigen Restriktionen, etc.); 

• die andere Teilkomponente dient zur Überprüfung der Restriktionen (bezogen auf 
die Reihenfolge der Arbeitsgänge, mit den zugehörigen Start- und Endzeiten 
innerhalb eines Auftrages). 

Bei der Überprüfung können Konflikte auftreten, die durch den Ausfall von Ressourcen 
(Maschinen, Personal, Material), oder die Überlastung von Kapazitäten bedingt sind und zur 
Verzögerung von einzelnen Arbeitsgängen und des gesamten Fertigungsauftrages führen. 

3.3 Die Anaiysekomponente 

Die Analysekomponente setzt sich aus zwei Knowledge-Sources zusammen: 

• Kapazitätsanalyse 

• Störungsbehandlung 

Die Kapazitätsanalyse vergleicht die verfügbaren Kapazitäten und die jeweilige Auslastung 
durch Fertigungsaufträge. Dabei werden sowohl über- als auch unterbelastete 
Kapazitätsplätze lokalisiert, was sich dann auf die Planungskomponente auswirken kann, 
falls schlecht ausgelastete und Engpaß-Ressourcen gefunden werden. Von der Knowledge- 
Source Kapazitätsanalyse werden Heuristiken erzeugt, die auf der Kontroll-Blackboard 
abgelegt werden und zu einem veränderten Scheduling führen können. Beispielsweise wäre 
ein mögliches Ergebnis, daß beim Scheduling immer zuerst die Engpaß-Ressourcen 
betrachtet werden. 

Die Störungsbehandlung betrachtet Störungen jeder Art (Maschinen, Personal, fehlendes 
Material) und schlägt Planrevisionsmethoden vor, die alle, oder zumindest einen Teil der 
betrachteten Störungen beheben sollen. Diese Vorschläge werden auf der Kontroll- 
Blackboard abgelegt, wodurch die Planungskomponente aktiviert wird. 

Das Konzept der Störungsbehandlung wird in Kapitel 4 ausführlich behandelt. 

Planrevisionsmethoden zur Konfliktbeseitigung sind beispielsweise: 
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• Ausweichen auf alternative Kapazitäten (alternative Maschinen, manuelle Fertigung, 
etc.), 

• Veränderung der Auftragsreihenfolge, 

• Verschiebung von Arbeitsgängen und Aufträgen, 

• Veränderung der Arbeitsgangreihenfolge. 



3.4 Planungskomponente 

Auch die Planungskomponente besteht aus zwei Knowledge-Sources, nämlich der 

• Reihenfolgeplanung und dem 

• Scheduler. 

Der Reihenfolgeplaner legt, unter Berücksichtigung vielfältiger Kriterien und Zielsetzungen, 
die Abarbeitungsreihenfolge der vom übergeordneten Planungssystem (PPS-System) 
freigegebenen Werkstattaufträge fest. Für zukünftige Verbesserungen dieser Komponente ist 
geplant, auch die Abarbeitungsreihenfolge der einzelnen Arbeitsfolgen an den 
Kapazitätsplätzen festzulegen. Diese Komponente könnte bspw. im Falle eines 
Kapazitätsausfalles aufgerufen werden. Es würde dann eine neue Arbeitsgangreihenfolge 
unter Berücksichtigung des ausgefallenen Kapazitätsplatzes generiert. 

Der Scheduler ordnet den einzelnen Arbeitsgängen Kapazitätsplätze innerhalb einer 
Kapazitätsgruppe zu und legt für jeden Arbeitsgang exakte Start- und Endtermine fest. 

3.5 Kontrollkomponente 

Um alle Knowledge-Sources zu koordinieren und einen effizienten Einsatz aller 
Systemkomponenten zu gewährleisten, wird Kontrollwissen benötigt. Kontrollwissen dient 
zur Steuerung der Aktivierung der am PlanungsprozeB beteiligten Teilsysteme. Es ist in einer 
übergeordneten Kontroll-Knowledge-Source aggregiert. Abhängig von der aktuellen 
Werkstattsituation und der jeweiligen Problemstellung wird die am besten geeignete 
Komponente (KS) von der Kontrollkomponente aktiviert. 
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Blackboards 

Im System existieren zwei verschiedene Blackboards, die Domänen-Blackboard und die 
Kontroll-Blackboard. Zu beiden Blackboards folgt eine exemplarische Aufzählung von darauf 
vorhandenen Daten: 

Domänen-Blackboard 

• Werkstattmodell 

• Kapazitätsplätze (evtl, gestört) 

• welche Arbeitsgänge, wo aktuell, in welchem Zustand sind 
(gefertigte Teilprodukte, Stückzahlen, Warteschlangen, ...) 

• Existenz u. Zustand von Materialien u. Werkzeugen 

• Transportsysteme 

• aktueller Belegungsplan: welche Arbeitsgänge künftig auf 
welchen Kapazitäten abgearbeitet werden sollen (Plantafel) 



Kontroll-Blackboard 

Problembeschreibungen, Ziele (Termintreue, 
Kapazitätsauslastungsoptimierung, ...) 

• Strategien, Heuristiken 

• Agenda von möglichen Planungsschritten 

• Durchgeführte Planungsschritte (Protokoll des 

Problemlöseprozesses) 



4 Fallstudie: Wissensbasierte Störungsbehandlung 

Die folgenden Ausführungen basieren auf Forschungsarbeiten die am Fachgebiet 
Systemanalyse und EDV in Zusammenarbeit mit einem Unternehmen der Fertigungsindustrie 
durchgeführt wurden. 

Der Gegenstandsbereich ist ein Fertigungssegment in dem Leiterplatten bestückt werden. 
Der Bestückungsprozeß vollzieht sich strukturell in den Schritten autom. SMD-Bestückung, 
autom. Axial-Bestückung, autom. Radial-Bestückung, Hand-Bestückung, Löten und Prüfen, 
wobei verschiedene Leiterplatten unterschiedlich hohen Aufwand an den einzelnen 
Belegungseinheiten erzeugen. Manche Leiterplatten beanspruchen einige 
Belegungseinheiten überhaupt nicht. 

Das im folgenden dargestellte Konzept zur Störungsbehandlung konnte bereits erfolgreich in 
einem Prototypen realisiert werden. 




129 




Storung {Mansch, Maschine, Material) 



Crulzm|l*ri«J 

AH»fn«i(VfnBin[ul 

EitHJp*r»niJ 



Kapi^AtspUtf ml 

ArlHitsvoFging 



Entscheidung 

h vtin 3«rungtdtolf] 






PtrtOAAl um^tnn 
B*rLKkt(cl1li(pjig Mm 

Abhan9^«rf»n 



Entscheidung 



BvtBguneMiniwi mU w- und r>tchg«iageri«n B«t«ichvi 



P«r«nal kuf/ihslg Urlaub arbston 
Pgraunal Inmm/di^mrn {FK$T] umaatian 
eefütktieribgung vor- untVaAr 
nachgtlagaflar Bffiicha 
tZwwEfAfiligcr, AilHitsvurral) 



Abb. 4: Konzept der Störungsbehandlung 



Um eine schnelle Reaktion auf eine auftretende Störung zu generieren und hieraus 
Maßnahmen abzuleiten, werden als Ausgangsdaten folgende Informationen benötigt: 



Betroffene Belegungseinheit (BE) 
Betroffener Kapazitätsplatz (KARL) 
Bearbeitetes Produkt (Auftrag) 
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• Störungskategorie (Mensch, Maschine, Material) 

• Fallweise die voraussichtiiche Störungsdauer 

Die Maßnahmen zur Störungsbehandlung gliedern sich in mehrere aufeinander aufbauende 
und miteinander verknüpfte Stufen (vgi. Abb. 4). Die in der Abbiidung dunkel hinterlegten 
Objekte symbolisieren den jeweiligen ebenenspezifischen Fokus. 

Die erste Stufe beinhaltet ein sogenanntes iokales Durchsetzungskonzept. Die wesentiiche 
Aufgabe dieser Durchsetzungsstufe ist die schnelle Störungsbeseitigung. Tritt an einem 
Kapazitätspiatz eine Störung auf, werden in Abhängigkeit von der Störungsart (Mensch, 
Maschine, Materiai) vom System Maßnahmen vorgeschlagen, die zu einer lokalen 
Störungsbehebung führen. Maßnahmen zur Störungsbehebung beziehen sich immer auf 
Möglichkeiten, die die Störungsursache direkt kompensieren. Bei Maschinenstörungen 
bedeutet das, daß Fehlerdiagnosen durchgeführt und Reparaturmaßnahmen vorgeschlagen 
werden. 

Liegt die Störungsursache im Materialbereich (fehlendes oder mangelhaftes Material), wird 
geprüft, ob entsprechendes Material oder ggf. Alternativmaterial im Lager verfügbar ist und 
venvendet werden kann/soll. Wird eine Störung durch fehlendes Personal verursacht, wird 
geprüft, ob für die entsprechende Arbeitsaufgabe qualifiziertes Personal verfügbar ist. 

Auf der zweiten Ebene werden Maßnahmen vorgeschlagen, die den Zweck verfolgen, 
auftretende Störungsauswirkungen zu begrenzen und/oder auf BE-Ebene eine Durchsetzung 
zu erreichen. Ziel hierbei ist es, die Auswirkungen einer Störung und möglicher 
Durchsetzungsmaßnahmen auf andere Belegungseinheiten so kiein wie möglich zu halten. 
Konnten auf Ebene 1 keine Maßnahmen ermittelt werden, die die Störung schneiistmöglich 
beseitigen, oder die Dauer der Störungsbehebung (Reparaturdauer, Transportzeit für 
Material, etc.) überschreitet einen definierten Schwellwert, müssen in der zweiten Stufe lokale 
Folgemaßnahmen und Ausweichmöglichkeiten erwogen werden. 

In Abhängigkeit von der voraussichtlichen Störungsdauer werden in dieser Stufe vom System 
Maßnahmen vorgeschlagen, die einerseits technologische Abhängigkeiten berücksichtigen 
und andererseits die aus der Störung resultierenden Konsequenzen mildern. Hierunter fallen 
beispielsweise Maßnahmen wie: 

• Stoppen von zeitlich direkt vor-/nachgelagerten Arbeitsgängen, wenn 
technologische Abhängigkeiten zu beachten sind, 

• Umsetzen von Personal. 

Neben der Milderung von Konsequenzen kommen auf BE-Ebene hier auch 
Durchsetzungsmaßnahmen in Betracht. Ist beispielsweise ein Kapazitätsplatz innerhalb der 
BE frei verfügbar, so kann bei einer Maschingnstörung auf diesen ausgewichen werden. 
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Hierbei ist jedoch wiederum der Umrüstaufwand in Abhängigkeit von der Störungsdauer zu 
berücksichtigen. Eine weitere Möglichkeit der Durchsetzung besteht darin, noch vorhandene 
Teilprodukte (Primärbedarf) aus dem Lager einzusteuern und so, unter Umgehung der 
Störungsquelle, den Auftrag sicherzustellen. Liegt die Störungsursache in fehlendem 
Personal, wird vom System geprüft, ob ein "Personalsplitting" möglich ist (z.B. ein Einrichter 
für zwei Maschinen). 

Kann auch auf dieser Stufe keine Maßnahme gefunden werden, die eine Durchsetzung 
ermöglicht und/oder das Ausmaß einer Störung ist so gravierend (lange Störungsdauer, kein 
Arbeitsvorrat für Folgearbeitsplätze), daß auch Konsequenzen für vor- und/oder 
nachgelagerte Fertigungsbereiche berücksichtigt werden müssen, erfolgt eine Verzweigung 
auf die dritte Stufe. 

Hier werden Durchsetzungsmaßnahmen erwogen, die Auswirkungen auf vor-und/oder 
nachgelagerte Werkstattbereiche haben und unter Umständen eine Planänderung erfordern. 
So wird beispielsweise unter Berücksichtigung von Auftragsprioritäten geprüft, ob andere an 
dieser BE laufende Arbeitsvorgänge unterbrochen werden können. Es wird ebenfalls 
erwogen, auf alternative BE's auszuweichen, wobei wiederum auftretende Konflikte zu lösen 
sind. Weiter wird geprüft, ob Konsequenzen für vor- und/oder nachgelagerte 
Fertigungsbereiche zu berücksichtigen sind (wachsende Zwischenlager vor dem gestörten 
Kapazitätsplatz; sinkender Arbeitsvorrat in nachgelagerten Bereichen). Dies kann zu einer 
erneuten Störungsbehandlung an der entsprechenden Belegungseinheit führen 
(Folgestörung). 

Lassen sich auch auf der dritten Ebene keine Durchsetzungsmaßnahmen finden, wird der 
Auftrag sistiert, wobei geprüft wird, ob andere Aufträge bevorzugt (keine Beanspruchung der 
gestörten Kapazitätseinheit) eingesteuert werden sollen/können, um so die Auslastung 
sicherzustellen. Ist die Einsteuerung solcher Aufträge möglich, wird dies als Vorschlag 
generiert. 

Auf allen Stufen werden Informationen von benachbarten Systemen verwertet, wobei auf der 
dritten Ebene der Informationsbedarf am höchsten ist. 

Dieses stufenweise Vorgehen bildet den Entscheidungsprozeß des Werkstattmeisters ab, der 
zuerst versucht, lokale Störungen mit lokalen Maßnahmen zu beseitigen, bevor aufwendigere 
Verfahren zur Anwendung gelangen, die hohen Abstimmungsaufwand erfordern. 

5 Zusammenfassung 



ln diesem Beitrag wurde, ausgehend von den Aufgaben, die für die Durchsetzung des 
Fertigungsprogrammes notwendig sind, gezeigt, wie komplex die einzelnen Teilaufgaben 




132 



sind, und das diese Teilaufgaben nicht mit konventionellen Ansätzen gelöst werden sollten. 
Das gilt insbesondere dann, wenn die Zielsetzungen einer bestandsarmen Produktion und 
kurzer Durchlaufzeiten verfolgt werden sollen. 

Darauf aufbauend wurden Ansätze und Konzepte aus dem Bereich der verteilten Künstlichen 
Intelligenz vorgestellt, die zur Lösung der Problemstellung herangezogen werden können. 
Weiter wurde gezeigt, daß der Bereich der DAI Möglichkeiten bietet, den in der Fertigung 
existierenden Problemlöseprozeß adäquat zu modellieren. Schließlich wurde ein an der 
Technischen Universität Berlin entwickelter Lösungsansatz, der auf Konzepten der DAI 
beruht, vorgestellt. 

Durch die Integration einer Störungsbehandlung gewinnt der Ansatz große Bedeutung. Im 
Falle einer Störung wird der Planungskomponente eine zuverlässige Angabe der 
Störungsdauer zur Verfügung gestellt und es können Heuristiken (Umplanungsstrategien) 
zum Einsatz kommen, die den aktuellen Plan, der von der Planungskomponente verwaltet 
wird, hinsichtlich einer Minimierung der Konsequenzen der Störung modifizieren. 
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Zusammenfassung 

Wissensbasierte Systeme können helfen, die Simulation für eine breitere Anwenderschicht 
nutzbar zu machen. Dazu werden Klassifikationen nach der Architektur und nach der Aufga- 
benteilung vorgestellt Letztere unterscheidet Programme zur automatischen Generierung von 
Modellen, Systeme, die den Benutzer bei der Interaktion unterstützen, und Expertensysteme, 
die Simulation zur Wissensakquisition nutzen. Als Beispiel wird SIMULEX vorgestellt, das 
durch Koppelung von Expertensystemen, Simulation und einem PPS-System die Umdisposi- 
tion in der Fertigungsplanung unterstützen soll. 
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1 Einleitung 

In den letzten Jahren war ein bedeutender Anstieg in der Verwendung von Simulationsmo- 
dellen zur Abbildung unterschiedlichster Systeme zu beobachten. Ursächlich hierfür sind die 
bekannten Vorzüge der Simulation, die in dem Maße weiter in den Vordergrund rücken, wie 
sich das Preis-/Leistungsverhältnis der Computer verbessert. 

Mit dem Einsatz von Simulation sind jedoch auch verschiedene Probleme verbunden: 

Fachleute, die die Fähigkeit und das nötige Wissen besitzen, valide Simulationsmodelle 
zu entwickeln und diese dann später zu betreuen, sind rar. 

Zudem sollte sich der Simulationsexperte mit dem abzubildenden System genau ausken- 
nen, um es einerseits wirklichkeitsnah abbilden zu können und um anschließend die 
Simulation mit passenden Parametern zu versorgen. 

Schließlich steigen die Ansprüche, was die Geschwindigkeit betrifft, in der ein Simulati- 
onsmodell zur Vorbereitung einer ad hoc-Entscheidung formuliert und durchgearbeitet 
sowie seine Lösung interpretiert wird. 

Um diese Hürden etwas niedriger zu legen, hat man zunächst ganz unterschiedliche problem- 
orientierte Simulationssprachen entwickelt, die jetzt auch auf PCs verfügbar sind. 

Darauf aufbauend wurde die Entwicklung von Werkzeugen forciert, die dem Entwickler und 
Bediener von Simulationsmodellen mit Hilfe graphischer Darstellung und/oder KI-Techniken 
zu größerem und schnellerem Erfolg verhelfen sollen. Dieser Trend wird zusätzlich durch die 
Entwicklung neuer spezialisierter Computerhardware, wie etwa Kl-Workstations, verstärkt. 

Ziel dieser Arbeit ist es, Möglichkeiten einer Verbindung von Expertensystemen (XPS) bzw. 
Wissensbasierten Systemen (WBS) mit der Simulation (S) zur Lösung von Produktions- 
problemen aufzuzeigen. 



2 Kooperationsformen zwischen XPS und S 

2.1 Klassifikation nach der Architektur (O'Keefe) 

Ein Versuch, die Verbindungsmöglichkeiten von XPS und S zu systematisieren, findet sich 
bei OKeefe ([8], S. lOff) Da viele Aufsätze darauf Bezug nehmen, soll dieser Vorschlag 
zunächst kurz dargestellt werden: 



1. Eingebettete Systeme 

Bei eingebetteten Systemen werden XPS und S gemeinsam entwickelt und implemen- 
tiert, wobei das jeweils eingebettete System (in Abb. 1 das XPS, in Abb. 2 die S) Be- 
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Standteil (z.B. in Form eines Unterprogramms) des umhüllenden Systems ist, auf das der 
Anwender ausschließlich Zugriff hat. 




Abb. 1: XPS eingebettet in S 




2. Parallele Systeme 

Im Gegensatz hierzu werden die parallelen Systeme getrennt entwickelt und implemen- 
tiert; sie stellen somit eigenständige Systeme dar, die jedoch miteinander kommunizieren 
können. So wird die Nutzung des XPS durch die S (Abb. 3) bzw. umgekehrt (Abb. 4) 
möglich. 





Abb. 3: XPS zur Unterstützung von S 



Abb. 4: S zur Unterstützung von XPS 



3. Kooperierende Systeme 

Von kooperierenden Systemen spricht O'Kecfe, wenn XPS und S getrennt entwickelt 
wurden, sie also selbständige Einheiten bilden, die jedoch im Gegensatz zu den vorher 
beschriebenen parallelen Systemen bei der Erfüllung von Aufgaben Zusammenarbeiten, 
wie es beispielsweise bei der Nutzung und Pflege einer gemeinsamen Datenbasis der Fall 
sein kann. 

Bei kooperierenden Systemen mit weiterer Softwareumgebung (Abb. 5) sind XPS und S 
in ein Programmpaket integriert, wobei es sich z.B. um ein Entscheidungsunterstützungs- 
system oder wiederum um eine S-umgebung handeln kann. 
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Im Falle von isoliert kooperierenden Systemen (Abb. 6) kann der Anwender auf beide 
Systeme direkt zugreifen, während im anderen Fall nur indirekt über die Softwareumge- 
bung Einfluß genommen werden kann. 





Abb. 5: Kooperierende Systeme mit wei- Abb. 6: Isoliert kooperierende Systeme 
terer Softwareumgebung 



4. Intelligent Front-End 

Das XPS in der Rolle eines Intelligent Front-End steht als Mittler zwischen S und An- 
wender (Abb. 7). Es übernimmt zum einen die Konfigurierung eines S-experiments und 
stellt die erforderlichen Parameter ein. Zum anderen wertet es die aus der S gewonnenen, 
meist unübersichtlichen und komplexen Daten aus und stellt sie dem Anwender in an- 
schaulicher und leicht verständlicher Form zur Verfügung. 

Durch die Zwischenschaltung des XPS kann auch der "Simulationslaie" die S leichter 
nutzen, da er nur mit dem XPS kommunizieren muß und die S so im Grenzfall für ihn 
zur "Black-Box” wird. 




Abb. 7: Intelligent Front-End 
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2.2 Klassifikation nach der Aufgabenteilung 
2.2.1 Vorbemerkungen 

Diese Einteilung stellt im Gegensatz zu OKeefe nicht auf die programmtechnische Koopera- 
tionsform ab, sondern unterscheidet, zu welchen Zwecken eine Zusammenarbeit zwischen S 
und XPS stattfindet. Im einzelnen sind dies: 

Modellgeneratoren, 

Zu- und Abgangssysteme sowie 

XPS, die mit Hilfe der S ihre Wissensbasis aufbauen bzw. erweitern. 

Im folgenden sollen diese drei Kooperationsformen genauer erläutert werden. 



2.2.2 Modellgeneratoren 

Ein großes Problem bei der Konstruktion von S-modellen ist die begrenzte Benutzerfteund- 
lichkeit der angebotenen Werkzeuge. Es werden leichter bedienbare Schnittstellen benötigt, 
die es dem Anwender ohne tiefergehende S-kennmisse erlauben, Modelle aufzubauen. Einen 
Versuch, dieses Problem zu lösen, ist in modernen S-sprachen, wie beispielsweise SIMKIT 
oder SIMFACTORY, zu sehen, wobei der Anwender jedoch immer noch großen Aufwand in 
den Aufbau von eigenen Programmbibliotheken stecken muß; dazu bedarf es wiederum der 
Fähigkeiten eines erfahrenen S-experten ([2], S. 648). 

Aus diesem Grund versucht man mit Hilfe von "Automatic Programming” (AP), also einer 
KI- Anwendung, die in der Lage ist, automatisch Programme zu generieren, dem Anwender 
auch diese Aufgaben abzunehmen. Solche AP-Systeme weisen folgende vier Charakteristiken 
auf ([11], S. 569): 

Sie bieten eine Problemspezifikationsmethode an, 

sie generieren Code in einer bestimmten Programmiersprache, 

sie sind nur gültig für einen beschränkten Problembereich und 

sic folgen bei der Programmcrstcllung einer genau bestimmten Prozedur. 

Schroer u.a. ([11], S. 569) beschreiben die Entwicklung eines solchen Programms für Pro- 
duktionssysteme ("Automatic Manufacturing Programming System” (AMPS)), wobei sic als 
S-sprache GPSS/PC verwenden. Ihr Ansatz bei der Erstellung des Systems teilt sich in fol- 
gende vier Phasen: 



Phase I: Definition einheitlicher Produktionseinrichtungen 

Abbildung 8 zeigt die grundlegenden Elemente einer Fcrtigungscinrichtung. Hier zeigt sich 
auch die oben erwähnte Eigenschaft von AP-Systemen, nur für einen beschränkten Problcm- 
bereich - hier die Fertigung - Lösungen anzubieten. Die ausgewählten Elemente reichen aus, 
nahezu jede Fertigung abzubilden. 
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Durch daa Zuaanunenfflgcn Ton Teil X und Teil Y 
entaUht TeU Z 


FertigungaataUon 


Durch Verlnderung dea Telia X entateht Teil Y 


Tranaporieiiiildituiig 


Teil X oder ein Loa Ton Teil X vird Ton LagerplaU A 
XU Lagerplatz B gebracht 


QuaUUtakontrollataUon 


Kontrolle Ton Teil X 


NachbearbeitungaaiaUon 


Durch eine Verarbeitung dea Tdla X entateht ein 
modifiziertea Teil X 



Abb. 8: Elemente zur Abbildung einer Fertigung 



Um die einzelnen Stationen zu charakterisieren, werden sie mit Attributen versehen, deren 
Inhalte später bei der Programmerstellung genauer spezifiziert werden. Abbildung 9 zeigt bei- 
spielhaft die Attribute einer Qualitätskontrollstelle. 



Charakteriatika 


Parameter 


Kontrollräte 


Prozent der zu kontrollierenden Teile 


KontroUzeit 


Art der Verteilung der KontroUzeit und die Parameter 
der Verteltungafunktion 


Schlechtteile 


Anteil der Telle, die die XontroDateUe nidit panieren 
können 


Reparaturdauer 


Art der Verteilung der Reparaturzeit und die Parameter 
der Verteilungifunktion 


Reparaturquote 


Prozent der Teile, die erfolgreich repariert werden 
konnten 


StaUonabeaetzung 


Anzahl der KbntroUenre und der Rqmraturfachlente 



Abb. 9: Parameter einer Qualitätskontrollstelle 



Phase n: Erstellen von Unterprogrammen zur Abbildung der Produktionseinrichtungen 

In dieser zweiten Phase müssen die Abläufe innerhalb der elementaren Produktionseinrich- 
tungen, die während Phase I definiert wurden, in detailliertere Schritte zerlegt werden. Abbil- 
dung 10 zeigt dies am Beispiel einer Qualitätskontrollstelle. Dies soll dazu dienen, einzelne 
Unterprogramme zu der jeweiligen S-sprache (in diesem Beispiel in GPSS), die auch Macros 
und Routinen zur Verfügung stellen, zu entwerfen und zu implementieren (vgl. auch [11]). 
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Abb. 10: Ablaui^lan einer Qualitätskontrollstelle 



Phase ni: Erstellen der Benutzerschnittstelle 

Aus den in Phase II erstellten Unterprogrammen kann ein erfahrener S-experte relativ schnell 
ein fertiges Modell entwerfen. Allerdings benötigt man bei dieser konventionellen Vorge- 
hensweise immer noch umfangreiche Kenntnisse der S-sprache, etwa um Variablen einzufü- 
gen, die zu Beginn des Programms definiert und initialisiert werden müssen. 

Um die Modellbildung auch Anwendern, die über diese Fähigkeiten nicht verfügen, zugäng- 
lich zu machen, haben Schroer u.a. [11] ein XPS entwickelt. Es erfragt im Dialog mit dem 
Benutzer den Aufbau des Systems sowie die Parameter der einzelnen Produktionseinrichtun- 
gen. 

In diese Phase könnten auch Vorschläge zur graphischen Unterstützung des Dialogs einge- 
bracht werden, wie sie beispielsweise Becker ([1], S.731) unterbreitet (vgl. Abb. 11). 
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Abb. 11: Graphische Unterstützung bei der Modellbildung (nach Becker) 

Phase IV: Generierung des GPSS-Codes 

In der letzten Phase muß schließlich ein Programm generiert werden, das aus den Be> 
nutzereingaben und den elementaren Produktionseinrichtungen ein Programm in der Zielspra- 
che generiert; in unserem Fall ist dies ein GPSS-Programm-Code. 




Abb. 12: Ablauf der automatischen Programmgenerierung 

Abbildung 12 zeigt für das eben dargestellte Beispiel den Ablauf von den Benutzerspezifika- 
tionen bis zum GPSS-Programm. Nach Probeläufen des Simulators kann der Anwender ein 
bestehendes Modell ändern. Dies könnte beispielsweise dann notwendig werden, wenn an- 
hand verschiedener S-modelle untersucht werden soll, welche Maschinen für eine neu zu 
konzipierende Werkstatt auszuwählen sind. 
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2.23 Zu- und Abgangssystem (Intelligent Front-Ends) 

Auf vielen Gebieten werden Anstrengungen unternommen, die Gebrauchsfahigkeit des ein- 
mal erstellten S-modells zu verbessern. Interaktive Bedieneroberflächen, graphische Eingabe, 
Animation während des S-laufs und Modellmanagementhilfen zielen auf vereinfachten Ge- 
brauch. Dennoch bleibt zumindest ein fundamentales Problem - die Durchdringung mehrerer 
S-phasen mit statistischen Methoden. Vielen potentiellen Anwendern fehlen hierzu die Basis- 
kenntnisse, oft genug steht ihnen professionelle Hilfe nicht zu Gebote. Deshalb wird oft die S 
unvollkommen bzw. falsch benutzt. 




Abb. 13: Statistische Methoden von SESSA 

An diesem Punkt setzen Zu- und Abgangssysteme an: Sie stellen dem Anwender einen 
"Statistikratgeber" in Form eines XPS zur Seite, der zum einen dabei unterstützt, einen S-lauf 
zu parametrisieien (Zugangssystem), und zum anderen helfen soll, die Ergebnisse des S- 
laufes zu analysieren (Abgangssystem). 
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Abbildung 13 zeigt eine von Mellichamp und Park ([6], S. 135) aufgestellte Tabelle, die er- 
kennen läßt, zu welchen Zeitpunkten der Anwender statistische Kenntnisse benötigt. Sie ha- 
ben mit SESSA (Statistical Expert System for Simulation Analysis) ein XPS konzipiert, das 
für jedes statistische Problem mehrere Methoden anbietet. Dies soll im folgenden an einigen 
Beispielen erläutert werden: 

1. Sammeln von Daten als Grundlage für die Inputvariablenschätzung 

Dem Anwender stehen vier verschiedene Methoden zur Verfügung, aus bestehendem 
Datenmaterial eine Stichprobe zu ziehen. Im einzelnen sind dies die Zufalls-, die Cluster, 
die geschichtete und die systematische Stichprobe. Das System unterstützt den Benutzer, 
in dem es zeigt, unter welchen Umständen die einzelnen Methoden für bestimmte Pro- 
blemstellungen geeignet sind. 

2. Schätzen von Daten für Inputvariable 

Es stehen zehn verschiedene Prozeduren zur Verfügung, um abzuschätzen, durch welche 
statistische Verteilung (z.B. Normal-, Exponential- oder Binomialverteilung) das Daten- 
material am besten repräsentiert wird. (Diese Festlegung ist im Zusammenhang mit der 
späteren Erzeugung von Zufallszahlen wichtig.) 

3. Festlegung der S-lauflänge sowie der Anzahl der S-läufe 

Um eine gewünschte Genauigkeit der S-ergebnisse zu erzielen, ist es notwendig, sowohl 
die Länge eines S-laufes wie auch die Anzahl der Wiederholungen richtig festzulegen. 
Um diese Auswahl treffen zu können, stehen dem System 22 verschiedene Formeln zur 
Verfügung. 

4. Erkennen von Gleichgewichtszuständen im S-modell 

Der Anwender kann je nach Situation aus acht verschiedenen Methoden wählen, mit de- 
ren Hilfe das S-System erkennt, ob es sich nach der Einschwingphase im Gleichgewicht 
befindet. Erst nachdem dieser Zustand erreicht ist, gehen die einzelnen Systemzustände 
in das S-Ergebnis ein. Im einzelnen sind dies die Methoden von Gafarian, Conway, Gor- 
don und Tochers sowie jeweils zwei Verfahren nach Fishman sowie Emshoff & Sisson. 



2.2.4 Wissenserwerb durch S-modelle 

Mit Hilfe der S kann man sich Wissen darüber verschalen, wie sich ein System verhält, wenn 
man für Stellgrößen, die der Systemsteuerung dienen, unterschiedliche Werte auswählt. Aus- 
gehend von verschiedenen Systemzuständen zu Beginn der S-läufe können dann als Ergebnis 
- unter Berücksichtigung der Zielvorstellungen - Aussagen darüber getroffen werden, in wel- 
cher Situation bestimmte Parametereinstellungen zu bevorzugen sind. Ein Beispiel ist die 
Auswahl einer Prioritätsregel im Rahmen der Kapazitätstenximierung bei unterschiedlichen 
Konjunktursituationen, Kundenauftragskonstellationen, Wartungszuständen der Betriebsmit- 
tel u.ä. Diese Kenntnisse können personell in die Wissensbasis eines XPS eingefügt werden. 
Doch wird man hierbei nur bedingt von einer direkten Zusammenarbeit zwischen S und WBS 
sprechen können. 
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Es zeichnen sich erste Erfolge mit Methoden induktiven Lernens ab, mit deren Hilfe aus S-er- 
gebnissen automatisch Produktionsregeln generiert und diese ohne personelles Zutun in die 
Wissensbasis eines XPS integriert werden können. Im produktiven Einsatz wird das S-modell 
nicht mehr benötigt; die so erstellte Wissensbasis erlaubt es dem XPS, autonom zu arbeiten. 

Ausgehend von diesen Überlegungen wird in der Folge ein Idealsystem skizziert, dessen Re- 
alisierung in vollem Umfang freilich sehr aufwendig wäre. Dieses Idealsystem kann man sich 
in drei Phasen gegliedert vorstellen: 

Phase I: Entwicklung der Lemumgebung 

Wichtig bei der Entwicklung lernfähiger Programme ist nach Simon ([12], S. 35) das Simulie- 
ren und Verstehen menschlichen Lernens. Deshalb stellt Schank ([10], S. 18ff) folgende 
Forderungen an eine Wissenserwerbskomponente: 

FORM: Das erlernte Wissen muß in geeigneter Repräsentation in die 

Wissensbasis eingefügt werden. 

ZUSAMMENHANG: Das gelernte Wissen muß in einen geeigneten Zusammenhang 

zum bisherigen Wissen gestellt werden. 

FORTSCHRITT: Zusätzlich eingebrachtes Wissen soll das System befähigen, 

komplexere Probleme als vorher zu lösen. 

WEITERENTWICKLUNG: Erlernte und dann angewandte Fähigkeiten sollen in neue Lern- 
prozesse einfließen. 

Unter den in der Literatur (z.B. Frank [3], S. 108) genannten Ansätzen kommen vor allem das 
Lernen aus Beispielen bzw. aus Beobachtung für einen Wissenserwerb von XPS durch S in 
Frage. 

In einem ersten Schritt muß deshalb eine Wissenserwerbskomponente entwickelt werden, die 
den oben genannten Forderungen entspricht Da es aber oftmals zu teuer oder gefährlich wäre, 
den Lemvorgang am realen System durchzuführen (beispielsweise die Steuerung explosions- 
gefährlicher chemischer Vorgänge), oder auch das reale System noch nicht existiert, muß ein 
S-modell konstruiert werden, das alle für eine Entscheidungsfindung relevanten Sachverhalte 
abbildet (vgl. Abb. 14). 

Die Wissenserwerbskomponente muß deshalb neben dem Wissen über das System, wie mög- 
liche Initialzustände, Stellgrößen, Parameter etc., und dem Wissen über Lemstrategien auch 
ihrerseits wieder ein Zu- und Abgangssystem (vgl. 2.2.3) besitzen. 
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Abb. 14: Aufbau des Simulationsmodells und der Wissenserwerbskomponente 



Phase n: Aufbau der Wissensbasis 

Die Wissenserwerbskomponente konfiguriert mit Hilfe des Zugangssystems, das auf das Sy- 
stemwissen zurückgreift, S-experimente, d.h. es werden ausgewählte Initialzustände mit ver- 
schiedenen Parametersätzen für die Stellgrößen bereitgestellt und die S-läufe schließlich an- 
gestoßen. 

Die Ergebnisse der einzelnen S-experimente werden vom Abgangssystem analysiert und ver- 
dichtet. Aufgabe der Lemkomponente ist es nun, aus diesen Ergebnissen Regeln zu generie- 
ren und diese in die Wissensbasis einzufügen (vgl. Abb. 15). 




Komponente ist ln dieser Phase nicht akUr 



Abb. 15: Aufbau der Wissensbasis 

Pierreval ([9], S. 64f) betont, daß es eine wichtige Eigenschaft von Lemtechniken ist, aus ei- 
nem Satz von Beispielen allgemeingültige Schlüsse zu ziehen. One solche Generalisierung 
setzt voraus, daß das System in der Lage ist, Gemeinsamkeiten zwischen Beispielen zu er- 
kennen und davon ausgehend eine konzeptionelle Definition dieser Gemeinsamkeiten zu ent- 
wickeln. 





146 



Eine wichtige Form solchen Lernens ist die "konzeptionelle Clusterung", deren Ziel es ist, 
Klassen von Objekten zu definieren, die diese Konzepte repräsentieren und daraus Regeln, 
die die Beziehungen der Objekte innerhalb einer Klasse erklären, zu entwickeln. 

Phase ni: Einsatz der generierten Wissensbasis 

In der letzten Phase kommt die generierte Wissensbasis zum produktiven Einsatz (Abb. 16). 
Das S-modell wird zu diesem Zeitpunkt nicht mehr benötigt, da alle Entscheidungen, die das 
XPS trifft, am realen System ausgeführt werden. 




Komponent« ixt in di«xer PIuum nicht akUr 



Abb. 16: Einsatz der generierten Wissensbasis 





Abb. 17: Verbesserung bzw. Erweiterung der Wissensbasis 
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Da aber der gesamte Dialog, der zwischen XPS und realem System geführt wird, und zusätz- 
lich Rückmeldungen protokolliert werden, kann nach Ablauf einer längeren Periode die Wis- 
senserwerbskomponente dazu eingesetzt werden, aus diesem Dialog neue Regeln zu generie- 
ren und diese dazu verwenden, die Wissensbasis zu vergrößern und zu verbessern (vgl. Abb. 
17). 

3 SIMULEX 

3.1 Überblick 

3.1.1 Die Rahmenbedingungen für SIMULEX 

In der Forschung zu PPS-Systemen werden heute vielfach neue Ideen verwirklicht, die in 
weitgehend neue Programmsysteme münden. Ziel der Forschungsvorhaben in der Abteilung 
Wirtschaftsinformatik an der Universität Erlangen-Nürnberg ist es dagegen, Standardpro- 
grammpakete nicht zu ersetzen, sondern diese um Wissensbasierte Elemente zu ergänzen. 
Somit kann man Neuerungen einbeziehen, ohne die bisher getätigten Investitionen in diesem 
Bereich hinfällig zu machen. Wir erachten diese Vorgehensweise als vorteilhaft, und auch in 
der Fachöffentlichkeit sind die bisherigen Reaktionen auf diesen Ansatz positiv. 

Im vorliegenden Projekt soll beispielhaft das PPS-Systems COPICS durch Wissensbasierte 
Simulation unterstützt werden. 

Das Vorhaben ist in die Forschung der Abteilung Wirtschaftsinformatik so eingebettet, daß 
sich zahlreiche Bezugspunkte ergeben [7]. Die wesentlichen Nachbaiprojekte sind: 

1. Rechnergestützte Parameterkonfiguration von PPS-Systemen am Beispiel der Modular- 
programme COPICS und RM-PPS (PAREX) 

2. Wissensbasierte Umdisposition (UMDEX) 

3. Wissensbasierte Schwachstellendiagnose (DIPSEX) 

4. Expertisesysteme als Variante von Expertensystemen. Dabei werden aus umfangreichem 
Zahlenmaterial kompakte Diagnosen in Form von Texten und Grafiken abgeleitet 

Es war zunächst nötig, ein Umfeld zu konstruieren, in dessen Rahmen die geplante Koopera- 
tion zwischen Expertensystem (XPS) und Simulation (S) stattfindet Das Grundkonzept für 
die im folgenden SIMULEX genannte Kombination aus Simulator, Zugangssystem Z und 
Abgangssystem A wird in Abb. 18 skizziert. 
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PPS-System 







HdaUr 



Abb. 18: SIMULEX 

Zur Darstellung einer realistischen Ausgangssituation wurde ein Modellbetrieb geschaffen, 
anhand dessen die Ergebnisse von SIMULEX übeiprüft weiden können. Die Daten, welche 
das PPS-System (in unserem Falle COPICS) an SIMULEX übermittelt, werden dann aus die- 
sem Modellbetrieb enmommen, der als nächstes etwas genauer erläutert wird. 



3.1.2 Der Modellbetrieb 

Der Modellbetrieb muß folgende Eigenschaften auf sich vereinigen: 

1. Es ist eine möglichst große Annäherung an die Realität anzustreben. 

2. Einerseits wird hinreichende Komplexität verlangt, so daß die mit dem System gefun- 
denen Lösungen nicht trivial sind. 

3. Andererseits soll die Komplexität begrenzt bleiben, um den Modellbetrieb überschaubar 
zu halten und die Rechenzeiten nicht zu lang werden zu lassen. 
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4. Damit dieses Modell auch im Lehrbetrieb eingesetzt werden kann, ist es wünschenswert, 
daß die hier gefertigten Produkte für den durchschnittlichen Studenten leicht verständlich 
sind. 

Wir haben ein Unternehmen gewählt, das Zweiräder herstellt. Die Fa. Hercules GmbH in 
Nürnberg hat uns dankenswerterweise Daten aus ihrer Fertigung überlassen, so daß unser 
Modellbetrieb in weiten Teilen als Nachbildung der tatsächlichen Produktion von Hercules 
angesehen werden kann. 

Im Teilestammbeieich des Modellbetriebes wurden ca. 700 verschiedene Teile eingetragen. 
Die Stücklisten wurden in Form von Baukastenstücklisten angelegt, da sich manche Teile, 
wie etwa Tretlager, in mehreren verschiedenen Fahrrädern verwenden lassen und so durch 
Verwendung des Baukastenprinzips die Umdisposition erleichert wird. 

Für jedes Einkaufsteil existiert ein Lieferant. Hs wurden ca. 25 verschiedene Lieferanten- 
stammsätze definiert. Das Modelluntemehmen produziert auf Lager. 

Der Produktionsbereich besteht aus den Abteilungen Rahmen- und Gabelbau, Teilefertigung 
und Vormontage sowie der Endmontage. Diese Abteilungen sind wiederum in mehrere 
Kostenstellen aufgegliedert, die ihrerseits mehrere Arbeitsplatzgruppen enthalten können. 
Insgesamt existieren 21 Kostenstellen mit zusammen 68 Arbeitsplatzgruppen. 

Bei den Arbeitsplänen gibt es teilweise Varianten. So kann beim Herstellverfahren für den 
Rahmen- und Gabelbau zwischen Hartlöten und Komplettschweißen gewählt werden. Die 
Arbeitspläne enthalten Ersatzkapazitäten (Ausweicharbeitsplätze). 

Datenverwaltung und Ablauforganisation der Produktion wurden so gestaltet, daß die Ferti- 
gung im Modellbetrieb mit COPICS geplant und gesteuert werden kann. 



3.U Verwendete Werkzeuge 

Zur Realisierung des unter 3.1.1 kurz dargelegten Konzepts wurden die folgenden Hilfsmittel 
ausgewählt: 

Als PPS-System wird das IBM-Paket CX)PICS benutzt. Zur Realisierung von Z und A kommt 
die ExpertensystemsheU ESE zum Einsatz, während die Implementierung des Werk- 
stattsimulators in GPSS-FORTRAN erfolgte. Die Wahl gerade dieser Programme läßt sich so 
begründen: 

Zum einen stehen die Pakete der Abteilung Wirtschaftsinformatik bereits zur Verfügung, so 
daß keine weiteren Kosten entstehen. Zum anderen handelt es sich bei COPICS um eines der 
weltweit am häufigsten installierten Großrechner-PPS-Systeme, und auch ESE und GPSS- 
FORTRAN sind seit längerem bekannt und eingeführt. Somit wird Realitätsnähe erreicht, da 
diese Kombination von Systemen auch in der betrieblichen Praxis anzutreffen ist. 
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Diese Wahl erscheint uns auch deshalb sinnvoll, weil sich mit der IBM 3090 eine gemein- 
same Haidwareplattform findet, die sowohl im Institut als auch in der Industrie vorhanden ist. 

Ein wesentlicher Aspekt ist weiterhin darin zu sehen, daß im Rahmen der Nachbarprojekte 
PAREX, DIPSEX und UMDEX weitreichende Erfahrungen mit COPICS und ESE zur Verfü- 
gung stehen. Auch mit dem Entwickler von GPSS-FORTRAN, Heim Prof. B. Schmidt, der 
lange Jahre im gleichen Gebäude gearbeitet hat und auch nach seinem kürzlichen Weggang 
nach Passau eine wissenschaftliche Gruppe am Institut für Math. Maschinen und Datenverar- 
beitung unterhält, gibt es regen Gedankenaustausch. Somit ist hier ebenfalls profundes 
Hintergrundwissen vorhanden. 

Genauso entscheidend war für uns die Tatsache, daß es relativ einfach möglich sein sollte, die 
Programme miteinander zu verknüpfen. Dazu stehen hauptsächlich zwei Mechanismen bereit: 

Zum ersten lassen sich aus ESE heraus FORTRAN-Prograpime aufrufen, so daß der Start ei- 
nes Simulationslaufes von Z aus erfolgen kann. Mittels dieser Schnittstelle zu externen Pro- 
grammen könnten auch laufend Ergebnisse an ESE zurückgemeldet werden. 

Zum zweiten bieten alle drei Programme eine Zugriffsmöglichkeit auf SQL-Datenbanken. 
Dadurch ist zunächst einmal eine reibungslose Übernahme der von CXDPICS bereitgestellten 
Grunddaten gewährleistet. Des weiteren erlaubt uns dies, der Forderung nach einer struktu- 
rierten Abspeichemng der Simulationsdaten zum Zwecke einer spätere^ Weiterverwendung 
nachzukommen. In Abb. 19 sind die Kommunikationsmöglichkeiten noch einmal schematisch 
dargestellt. 



PPS-Svstem 




Zugangs-ZAbgangs- 

svstem 


COPICS ) 


ESE 2.0) 


X 


Daten- 

ÜjankJ ^ 


r 




Werkstattsi mu lator 


GPSS-FORTRAN 
Version 3 



Abb. 19: Schnittstellen der Komponenten 
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3.2 Komponenten von SIMULEX 



3.2.1 Der Simulator 

Der Simulator bildet die Fertigung von Zweirädem ab. Er wurde mit Hilfe von GPSS- 
FORTRAN Version 3 realisiert Die Entwicklung erfolgte ursprünglich auf einem PC und 
wurde später auf einer IBM 3090 komplettiert 

Es wurde versucht, alle relevanten Details der Fertigung nachzubilden. So ist es unter 
anderem möglich, sehr kurze Vorgabezeiten bei der Bearbeitung, wie sie z. B. bei Stanzar- 
beiten Vorkommen, zu berücksichtigen. Zu diesem Zweck wurde die Simulationsuhr auf 
Hundertstelminuten eingestellt. 

Die vom Simulator betrachteten Komponenten der Durchlaufzeit eines Arbeitsganges ent- 
sprechen im wesentlichen denen in COPICS. Es sind dies Transportzeiten, Wartezeiten und 
Rüstzeiten, zum Teil in differenzierter Form; beispielsweise kann sich durch Lagerfehlbe- 
stände eine zusätzliche Wartezeit ergeben. 

Mit Hilfe zweier Zufallszahlengeneratoren werden Ausschußanteile und Maschinenausfall- 
zeiten ermittelt Während der Bearbeitung eines Loses können mehrere Maschinenausfälle 
eintreten. 

Liegezeiten werden bei der Ermitdung der Startzeit des Auftrages auf der Folgemaschine be- 
rücksichtigt. 

Die Simulation des Routing erlaubt flexible Umdispositionen bei der Belegung von Arbeits- 
einheiten, um z. B. Parallel- oder Ausweicharbeitsplätze einzusetzen. Auch die Ankunft 
firemdbezogener Lagerteile wird mit einer eigenen Funktion abgebildet. 

Als Politik, nach der die wartenden Aufträge bei Freiwerden der Bearbeitungsstation diese 
Warteschlange verlassen dürfen, wurde PFIFO gewählt. D. h., daß zuerst nach Priorität und 
bei gleicher Priorität nach der Ankunftszeit abgearbeitet wird. Eilaufträge können, mit einer 
hohen Priorität ausgestattet, weniger eilige Aufträge überholen. Ein angearbeiteter Auftrag 
kann nicht mehr verdrängt werden. Der Simulator enthält eine relativ anspruchsvolle Pau- 
senregelung. Dadurch können Fälle wie der, daß das Simulationsende in eine Pause fällt, be- 
rücksichtigt werden. 

Beispielhafte Verwertungsmöglichkeiten der Simulationsergebnisse sind: 

- Engpaßbestimmung bei Arbeitsplatzgmppen 

- Aufdeckung von Lagerfehldispositionen 

- Analyse der Auswirkungen von Maschinenausfällen 

- Analyse der Auswirkungen von Prioritätsänderungen 

- Analyse der Auswirkungen von Schichtänderungen 

- Analyse der Auswirkungen von Losgrößenvariation, Splittung und Überlappung. 




3.2.2 Das Zugangssystem 
3.2.2.1 Überblick 
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In Abbildung 20 wird das Zusammenspiel der Komponenten des Zugangssystems dargestellt. 
Eine genauere Eiklärung der jeweiligen Programmteile findet sich in den folgenden 
Abschnitten. 



EINGANGSDIALOG 




Störung ermitteln (Art, Dauer) 

Präferenzen festlegen (Analyse breitAief) 
Randbedingungen einstellen (Zeitraum, 
Genauigkeit) 

Vorauswahl in Frage kommender Aufträge 




SIMULATOR 



Abb. 20: Komponenten von Z 
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S.2.2.2 Der Eingangsdialog 

Im Rahmen dieses Dialogs sind zunächst die Störungen zu erfassen. Diese können auf zwei 
Wegen an SIMULEX herangetragen werden: 

- Durch das PPS-System COPICS 

Betrachtet man CX)PICS als "Black Box", so werden die Störungen über drei Informati- 
onskanäle in das System eingeleitet (vgl. Abb. 21). 



Störungen durch geänderte 
Kiindcnaufträge 
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Störungen aus dem 
Fremd bezugsberei ch 



Störungen aus dem 
Ei genf ertigungsbcrcich 



Abb. 21: Informationskanäle für Störungen bei CDPICS 

COPICS verfügt über keine aktuellen Produktionsdaten, sondern erhält Informationen 
über Störungen nur durch Rückmeldungen der Maschinenbediener bzw. des Leitstand- 
personals, wenn ein Auftrag fertiggestellt oder unterbrochen wurde. Erst zu diesem Zeit- 
punkt kann es SIMULEX, oft nur verspätet, zu einem Umdispositionslauf anstoßen. 

Genausowenig werden in COPICS Daten über die Ursachen einer Störung gespeichert. 
Deshalb ist das PPS-System auch nicht in der Lage, die voraussichtliche Störungsdauer zu 
prognostizieren. Diese muß durch das Personal abgeschätzt und manuell eingegeben wer- 
den. 

Durch den Bediener/Meister 

Sind schnelle Maßnahmen gefragt, so muß der Meister auch direkt einen Umdispositi- 
onslauf anstoßen können, damit er nicht allein auf eine routinemäßige Überprüfung der 
COPICS-Daten angewiesen ist. 

Eine allgemeine Klassifizierung der Störung nach Stärke und Reichweite dürfte in diesem 
Stadium allerdings noch nicht möglich sein, da die tatsächlichen Auswiikungen stark von der 
gewählten Umdispositionsmaßnahme äbhängen. Die eigentliche Bewertung wird daher - für 
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jede Maßnahme gesondert - von den einzelnen Agenten der Maßnahihen getroffen. Sie ist 
nicht zuletzt für die abschließende Beurteilung der geeignetsten Alternative nötig, um etwa 
eine Kosten/Nutzen> Analyse durchführen zu können. Sie kann aber auch dazu dienen, Benut- 
zern mit unzureichender Qualifikation bestimmte Möglichkeiten zu sperren. Schließlich las- 
sen sich damit in hierarchischen PPS-Systemen übergeordnete Umdispositionsmechanismen 
triggern. 

Als Erweiterung bietet sich an dieser Stelle eine genauere Analyse der Störungsursache im 
Rahmen einer Schwachstellendiagnose an, um langfristig Auslöser von Fertigungsproblemen 
zu identifizieren. 

Wie bereits erwähnt, sollte auch die Benutzerqualifikation erhoben werden. Zum einen ergibt 
sich daraus (im Sinne eines Benutzermodells) der verwendete Grad an Hilfestellung und die 
Detailliertheit der Fragen, zum anderen wird die Bereitstellung von Maßnahmen von der 
Kompetenz des Disponenten abhängen. 

Ein weitere Aufgabe liegt darin, die Zielvorgaben für die abschließende Empfehlung zu 
bestimmen. Hier muß der Benutzer auch die Bedeutung von Aufträgen festlegen können, 
deren Wichtigkeit sich nicht aus den bisherigen Erhebungen ergibt. Typischer Fall ist etwa 
ein Pilotprojekt in kleiner Stückzahl für einen potentiellen Neukunden, an das die Vergaben 
eines großen Folgeauftrages geknüpft ist Durch die Option, das Zielfunktional gezielt zu 
beeinflussen, ließe sich dieser Situation Rechnung tragen. 

ln diesem Zusammenhang könnte man auch die Möglichkeit vorsehen, eine Wahl zwischen 
einer eher tiefen Analyse weniger Alternativen oder einer eher breit angelegten Untersuchung 
des gesamten Maßnahmenspektrums anzubieten. 

Schließlich sind noch die Rahmenbedingungen der Simulation einzustellen. Zunächst ist dafür 
die gewünschte Genauigkeit der Ergebnisse festzulegen, also etwa das Signifikanzniveau, das 
die Simulationsergebnisse erreichen sollen. Auch die der Simulation zur Verfügung stehenden 
Zeit muß bestimmt werden, damit das System praktisch nutzbar ist. Diese Angaben dienen 
dem Dispatcher als Selektionskriterien für die Auswahl der zu simulierenden Modelle. 



3.2^.3 Die Methodenagenten 

SIMULEX stehen unterschiedliche Umdispositionsmaßnahmen zur Verfügung, aus denen es 
auswählen kann. Sie sind in Abb. 22 nach der voraussichtlichen Tragweite ihrer 
Auswirkungen gegliedert Maßnahmen im Kapazitäts-(KP-)Bereich ziehen den geringsten 
Umdispositionsaufwand nach sich. Man wird daher versuchen, zunächst mit solchen 
Methoden die Störung zu beheben. Über den Werkstattauftrags-(WA-), den Auftragsnetz- 
(AN-) bis hin zum Kundenauftrags-(KA-)Bereich steigt der Aufwand stetig an. 

Für jede dieser Alternativen existiert ein Methodenagent, in dessen Wissensbasis alle 
relevanten Informationen zur jeweiligen Maßnahme enthalten sind. Diese haben im 
wesentlichen drei Aufgaben zu erfüllen. Zunächst ist eine Aussage darüber zu treffen, ob und 
in welchem Maße eine Umdispositionsmaßnahme anwendbar erscheint Gerade für solche 
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Klassifikationen erscheint uns ein XPS als geeignetes Mittel. Dann sind, falls notwendig, die 
Panuneter der Maßnahme sinnvoll einzustellen, etwa die Splittingschlüssel oder die 
Zeitspanne, um die Wartungsarbeiten zurückgestellt werden sollen. Schließlich müssen einer 
übergeordneten Instanz alle unmittelbar betroffenen Maschinen gemeldet werden. Sinn dieser 
Maßnahme ist es, später nur den unbedingt erforderlichen Ausschnitt der Fertigung 
simulieren zu müssen. Dadurch werden sowohl die Übersichtlichkeit der Modelle erhöht als 
auch die Laufzeit der Simulationsexperimente verringert. 
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Abb. 22: Umdispositionsaltemativen 

Für die Implementierung der Agenten boten sich nach unserer Einschätzung folgende 
Alternativen im Design an, die sich im Umfang der pro Agent durchgefühlten Analyse 
unterscheiden. Zum einen kann sich jeder Agent darauf beschränken, alle unmittelbar 
betroffenen Maschinen an den Dispatcher zu melden und sonst weiter keine Untersuchungen 
über die Reichweite der Störung durchzuführen. Nachdem der Dispatcher die zu 
simulierenden Methoden ausgewählt hat, würde in diesem Fall anschließend eine zentrale 
Prozedur alle so gemeldeten Maschinen zusammenfassen und daraus ein für alle Alternativen 
gleiches Ausgangsmodell zur Simulation bereitstellen. 

Ein Vorteil dieses Ansatzes ist zum Beispiel, daß der wichtige Teil der Modellbildung von 
den Methodenagenten entkoppelt ist. Er konnte daher separat entwickelt werden und liefert 
ein einheitliches Ausgangsmodell. Dies wiederum erhöht die Vergleichbarkeit der einzelnen 
Alternativen. 

Andererseits werden so manchmal unnötig große Modelle simuliert, was sich nachteilig auf 
Speicherplatz- und Rechenzeitbedarf auswirkt. Außerdem bedeutet dies auch einen Informa- 
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tionsverlust, da man aus dem Umfang der einzelnen Modelle auf die Komplexität und damit 
auch Störanfälligkeit der Methoden schließen könnte. 

Weitediin sind bei dem vorliegenden Simulator statische und dynamische Modellteile nicht 
getrennt Die ganze Information steht vielmehr in den Arbeitsdatensätzen, die z.B. sowohl 
Routing- als auch Arbeitsganginformationen beinhalten. Man kann daher keine weiteren 
Vorteile aus dem einheitlichen Modell ziehen, denn beim Vergleich der Alternativen wird mit 
dem Stand der Fertigung stets auch ihr Layout gespeichert und geladen. 

Die vorher in Erwägung gezogene Struktur sah dagegen vor, daß jeder Methodenagent das 
Auftragsnetz selbst analysiert und ein auf seine Maßnahme speziell zugeschnittenes Modell 
aufbaut. Vor- und Nachteile sind gegenüber der ersten Möglichkeit entsprechend verkehrt 
Um Verzerrungen zu vermeiden, müßte allerdings jeder Agent sein Modell in der gleichen 
Qualität aufbauen, daher würde man eventuell doch nur einen Algorithmus konstruieren und 
in jede Methode kopieren. Dasselbe Ergebnis läßt sich aber auch mit der anderen Alternative 
erzielen, indem man die zentrale Prozedur nacheinander über die von den einzelnen Agenten 
gelieferten Daten laufen läßt, ohne erst die Vereinigungsmenge aller betroffenen Maschinen 
zu bilden. 

Schließlich ist noch zu beachten, daß das für die Abschlußanalyse vorgesehene Multiple- 
Ranking- Verfahren natürlich identische Ausgangsgrößen zum Vergleich benötigt, in diesem 
Falle wären das die Abweichungen von den Fertigstellungsterminen aller relevanten Aufträge. 
Obwohl bei unterschiedlichen Modellen nicht sichergestellt ist, daß diese Aufträge auch in 
jedem Modell voikommen, müßte man diese Variablen doch in jeden Fall mitführen. Man 
könnte dann etwa davon ausgehen, daß nicht betroffene Aufträge keinen ungeplanten Abwei- 
chungen unterliegen und für diese Fälle die Abweichung als Null definieren. 

Es empfiehlt sich, auf jeden Fall eine Umdispositionsmaßnahme "nichts tun" mitzusimulie- 
ren. Zum einen erhält man daraus ein Kriterium, ob überhaupt Handlungsbedarf besteht, zum 
anderen gewinnt man so eine "Kontrollpopulation", die den Einsatz einer Zahl weiterer Ver- 
fahren erlaubt 



S.2.2.4 Der Dispatcher 

Ein TeU der durchzuführenden Aufgaben ist bereits im vorhergehenden Abschnitt beschrie- 
ben. Dieses Modul wählt also anhand der Beurteilung der Anwendbarkeit die am günstigsten 
erscheinenden Maßnahmen aus und sorgt dafür, daß bestimmte Aufträge oder Maschinen auf 
jeden Fall mitsimuliert werden, falls der Benutzer dies eingangs angegeben hat Mit Hilfe die- 
ser Angaben wird dann der zu simulierende Fertigungsausschnitt generiert. Für jede ausge- 
wählte Methode wird die Durchführung der Simulationsexperimente vorbereitet, indem pas- 
sende Steuerdatensätze angelegt werden. Dabei müssen alle Umdispositionsmaßnahmen in 
den Werkstattauftragsdaten abgebildet werden. Sollen beispielsweise an einer Kapazitätsein- 
heit Überstunden angesetzt werden, so hat man diese in den Werkstattkalender aufzunehmen. 
Bei der Benutzung von Ausweichkapazitäten muß im Auftragsdatensatz die entsprechende 
neue Maschinenkennung eingegeben werden. Dazu gehören natürlich auch abweichende Be- 
arbeitungszeiten, Ausschußmengen, etc.. 
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Ursprünglich war an dieser Stelle auch eine Berechnung des Laufzeitbedarfs der einzelnen 
Alternativen geplant, um in der zur Verfügung stehenden Zeit möglichst viel simulieren zu 
können, ohne zu überziehen. Dieser Schritt muß jedoch entfallen, da die tatsächlich benötigte 
Laufzeit auf einer Mehrbenutzermaschine zu stark von Faktoren wie der allgemeinen Ausla- 
stung abhängig ist, so daß uns eine Prognose zu unsicher erscheint 

Dies stellt allerdings keinen gravierenden Nachteil dar, weil die geplante Ranking-Prozedur 
für die Analyse in mehreren Phasen abläuft und so eine ad-hoc-Kontiolle des Zeitbedarfs 
erlaubt 



3.23 Die Simulationssteuerung 



3 . 23.1 Auswahl der Anfangszustände 

Einschwingphasen, wie sie üblicherweise bei Simulationsexperimenten auftreten, braucht 
man nicht zu beachten, denn SIMULEX setzt nicht auf einer beginnenden, sondern auf einer 
laufenden Fertigung auf. Das (simulationstechnische) Gleichgewicht ist dadurch von Anfang 
an eingestellt Alle Beobachtungen, die so im Simulationsexperiment gemacht weiden, kön- 
nen also von Anfang an in die später folgende Auswertung einbezogen weiden. 



3 . 23.2 Auslegung der Einzelexperimente 

Hier gibt es im Vergleich zu anderen Forschungsprojekten einige Besonderheiten zu berück- 
sichtigen. 

Da man völlig freie Hand bei der Auslegung der Einzelexperimente hat, läßt sich dies als ein 
Problem des Experimental Design betrachten. Außerdem könnte man versuchen, innerhalb 
der Simulationsläufe selbst eine Form der Optimierung durchzufuhren (Ziel ist ja, den Vektor 
"Abweichung vom geplanten Endtermin" zu minimieren). 

Die einzelnen Umdispositionsmaßnahmen sind jedoch strukturell so verschieden, daß man sie 
nicht einfach als verschiedene Ausprägungen eines Parameters darstellen kann (dies ist nur 
möglich, falls man etwa Splitting in verschiedene Anzahl von Losen vergleichen wollte). So- 
mit sind die Methoden des Experimental Designs wie Blocking, Factoiial Design etc. nicht 
anwendbar. Dieses Defizit wird aber dadurch ausgeglichen, daß situationsspezifisches Ex- 
pertenwissen in die Vorauswahl der Alternativen und, falls anwendbar, in ihre Parame- 
tereinstellungen einfließt. 

Der unterschiedlichen Methoden stellen also qualitative Einflüsse dar. Somit sind sie erst 
recht nicht kontinuierlich oder gar differenzierbar, so daß auch die Gradientenmethode oder 
andere Verfahren der Surface Response Methodology entfallen. An ihre Stelle treten die 
Muldple-Ranking-Verfahrcn, insbesondere wohl Subset-Selection-Proceduies, die der Aus- 
wahl der "k besten" Möglichkeiten dienen. 
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3.233 Festlegung der Lauflänge und -anzahl 

Hier muß ein Kompromiß zwischen den konkurrierenden Zielen "geringe Rechenzeit" und 
"hohe Zuverlässigkeit der Ergebnisse" gefunden werden, wenn man die Anzahl der Simulati- 
onsläufe sowie den Simulationshorizont festlegt. Die Lauflänge ist einmal durch den 
Planungshorizont von COPICS beschränkt. Die sinnvolle Länge eines Laufes wird auch 
dadurch begrenzt, daß die Störgrößen wie Maschinenausfälle, Einschleusung von Eilaufträgen 
etc. mit fortlaufender Zeit immer weniger vorhersehbar sind und sich allzu lange Läufe daher 
selbst ad absurdum führen würden. 

Das Ziel der Simulation besteht zunächst darin, statistisch signifikant diejenigen Maßnahmen 
herauszufiltem, die - als "hartes Kriterium" - die beste Termintreue gegenüber den geplanten 
Endterminen aus COPICS versprechen. Es handelt sich hierbei also um ein Multiple- 
Ranking-Problem, Ziel ist es, den Vektor "Abweichung vom geplanten Endtermin" zu mini- 
mieren. Zur abschließenden Analyse kann man dann zum Beispiel davon ausgehen, daß mit 
95%iger Sicherheit tatsächlich die in dieser Beziehung besten Maßnahmen gegenübergestellt 
werden. 

Die Abstufung der so gefundenen Maiinahmen nach "weichen Kriterien" wie Aufwand und 
Risiko erfolgt dann wieder regelbasiert. Durch die in der XPS-Shell integrierte Erklärungs- 
komponente lassen sich diese Entscheidungen dann auch leichter dem Anwender nahebrin- 
gcn. 

Es ist allerdings extrem schwierig, überhaupt geignete Auswahlprozeduien zu finden, die eine 
Reihung mehrerer Populationen unter Berücksichtigung mehrdimensionaler Zielfunktionen 
erlauben! Es kann nämlich nicht davon ausgegangen werden, daß die Abweichung vom End- 
termin eine n-dimensional normalverteilte Zufallsgröße darstellt. Außerdem sind die Ergeb- 
nisvektoren der einzelnen Alternativen wohl unabhängig, jedoch kaum identisch verteilt 
Somit scheiden die "klassischen Verfahren" des multivarianten Rankings von vomeherein 
aus. Im Allgemeinen hat man auch überhaupt keine Informationen über die wahre Verteilung 
der Terminabweichung. Man ist also auf die Verwendung verteilungsfteier Verfahren ange- 
wiesen. 

Als besonders geeignet erscheint uns dabei Methoden, die das Problem auf eine multinomiale 
Auswahl reduzieren ([4], [5]): 

Hierbei wird zunächst für jede zu betrachtende Alternative ein Simulationslauf durchgeführt. 
Anschließend wird beurteilt, welche Alternative beim augenblicklichen Ausgang der Läufe 
die günstigste gewesen wäre, diese eriiält dann einen Punkt zugesprochen. Durch mehrfache 
Wiederholung dieses Verfahrens erhalten die einzelnen Methoden unterschiedliche 
"Erfolgswahrscheinlichkeiten"; auf diese relativen Häufigkeiten bezieht ' sich darui das 
Reihungs- und Auswahlverfahren. Hierdurch erhält man auch eine Form der Laufzeitkon- 
trolle, da sich Analysen und Simulationsläufe mehrfach abwechseln. Bei Zeitnot läßt sich 
daher die Simulation vorzeitig beenden und auf entsprechend niedrigerem Signifikanzniveau 
mit der Analyse fortfahren. Für die so gefundene Teilmenge lassen sich dann bei Bedarf 
durch weitere Simulationsläufe genauere Parameterschätzungen gewinnen. 
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3.2.4 Das Abgangssystem 

Das Abgangssystem besteht im wesentlichen aus einer Bewertung der Simulationsergebnisse 

mit einer nachgeschalteten Erklärungskomponente. Genauer betrachtet ergibt sich folgende 

Aufgabenteilung: 

1. Zunächst müssen die Simulationsergebnisse hinsichtlich globaler statistischer Kenngrö- 
ßen wie Mittelwert und Standardabweichung, Modus, Schiefheit, Median, Quantil etc. 
untersucht werden, um deren sinnvolle Verwendbarkeit zu verifizieren. Die voigeschla- 
genen Verfahren zur "Auswahl der Besten" stellen dabei eine soliide Basis für weiter- 
gehende Analysen dar. 

Dabei gestaltet sich auch hier die simultane Konstruktion von Konfidenzniveaus als pro- 
blematisch. Daher ist noch unklar, inwieweit sich die Parameterschätzungen über mitt- 
lere Warteschlangenlängen, Liege- und Transportzeiten etc. als Kriterien heranziehen 
lassen. Schließlich ist hier weder sichergestellt, daß alle Parameter normalverteilt sind, 
noch kann man von identischen Verteilungen derselben Größe bei unterschiedlichen 
Umdispositionsmaßnahmen ausgehen. Somit ergeben sich für eine quantitative Beurtei- 
lung dieselben Schwierigkeiten wie beim Ranking der Terminabweichungen. Um ein 
gemeinsames Konfidenzintervall zu bestimmen, läßt sich wohl nur - bei bekannter Zahl 
von Alternativen - die Bonferroni-Ungleichung verwenden. 

2. Zusätzlich zu quantitativen Kriterien, wie Termintreue, Kapazitätsauslastung etc., sind 
noch qualititative Aspekte wie die Zufriedenheit wichtiger Kunden oder die Vermeidung 
unpopulärer Maßnahmen, z. B. Überstunden, in die Überlegungen einzubeziehen. 

3. Diese Nutzen- imd Aufwandsabschätzungen dienen als Ausgangspunkt für die endgültige 
Bewertung der einzelnen Alternativen. Die Selektion der Maßnahmen stellt sich so als 
ein dreistufiger Prozeß dar: zunächst Vorauswahl aufgrund einer Anwendbarkeitsbe- 
trachtung, dann statistisch begründbare Reduktion auf Maßnahmen, die das Primärziel 
bestmöglich erfüllen, und schließlich eine Einstufung derselben nach den Sekundäikri- 
terien. 

4. Abschließend werden die Resultate in Form einer Expertise dem Benutzer zugänglich 
gemacht Hierin sollen aber nicht nur die reinen Wertungen, sondern genauso Begrün- 
dungen der Vorschläge sowie Hinweise auf eventuelle Risiken enthalten sein, um den 
Nutzen sowie die Akzeptanz dieser Expertise zu erhöhen. Auch an dieser Stelle wird uns 
zugute kommen, daß das Abgangssystem mittels einer Expertensystemshell implemen- 
tiert werden soll. 

Bei der Expertise selbst ist eine Anpassung von Breite und Tiefe der gegebenen Erläute- 
rung an den Kenntnisstand des Bedieners wünschenswert Als theoretische Grundlage 
hierzu dienen Benutzermodelle, zu denen bereits aufgrund anderer in der Abteilung 
durchgeführter Projekte Erfahrungen vorhanden sind. 

Schließlich sollte auch ein Überblick des Fertigungstandes bei Simulationsende möglich 
sein, um negative Spätfolgen einzelner Maßnahmen ins Kalkül ziehen zu können. 
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3.3 Ablauf einer SIMULEX-Sitzung 

Abbildung 23 zeigt die schematische Darstellung des Ablaufs einer SIMULEX-Sitzung. 




Abb. 23: Ablauf einer SIMULEX-Sitzung 















161 



3.4 Mögliche Erweiterungen von SIMULEX 

Während der Beschäftigung mit dem zugrunde liegenden Modell und während des Literatur- 
studiums sind einige Anregungen entstanden, die - evtl, auch als spätere Ergänzung - dem 

System zusätzliche Fähigkeiten vermitteln sollten. Dies wären im einzelnen: 

1. Im üblichen Simulatorbetrieb werden die Parameter, die externe Systemeinflüsse darstel- 
len, normalerweise nicht dynamisch verändert. Im Werkstattmodell sind dies etwa die 
Verteilungsart und -parameter von Maschinenausfallzciten, Auftragsgrößen und An- 
kunftszeitpunkten etc. Es ist klar, daß die Simulationsergebnisse in ihrer Qualität im we- 
sentlichen von der Güte der Anpassung dieser Einstellungen an die Realität abhängen. 

Gerade in diesem Punkt haben die bisher verwendeten Simulatoren den Nachteil, daß zur 
korrekten Vorbesetzung der angesprochenen Werte sowohl statistisches Wissen als auch 
Kenntnisse des Simulators notwendig sind. Außerdem erfordert die Festlegung zunächst 
eine aufwendige Ausgangsdatenerhebung. Selbst wenn diese Einstellung aber nun einmal 
richtig durchgeführt wurde, ist fraglich, ob im täglichen Betrieb die Schwankungen die- 
ser Parameter erkannt und entsprechend nachgeführt werden. Dabei ist gerade im Zeital- 
ter immer kürzer währender Produktzyklen und häufig veränderter Marktlage, aber auch 
schon bei Maschinenaustausch, eine signifikante Veränderung der Daten zu erwarten. 

Es sind nun in anderem Zusammenhang Vorschläge für XPS unterbreitet worden, die 
sich speziell mit der Auswahl bester Verteilungsnachbildungen anhand empirischer Aus- 
gangsdaten befassen. Eine solche Zusatzfunktion ließe sich gut als Bestandteil des Z im- 
plementieren. 

Hier würde dann auch wieder die mögliche Verzahnung mit COPICS zum Tragen kom- 
men, da dieses Analysesystem seine Informationen zum Teil direkt aus den gelieferten 
Auftragsdaten ableiten könnte. Durch ein "rollierendes Analysefenster" wäre dann die 
automatische Anpassung gewährleistet. Im Sinne der später noch erwähnten Kooperation 
Z-A ließen sich nun schließlich auch erste Vorschläge für geeignete Analyseverfahren 
erstellen. 

2. Um auch die in letzter Zeit häufiger erwähnte Möglichkeit des "Realtime-Rescheduling" 
zu unterstützen, könnte man sich in einem weitergehend automatisierten Betrieb zusätz- 
lich eine Schnittstelle zur Betriebsdatenerfassung (BDE) denken, die dann Daten in 
Echtzeit aufnehmen würde. Die Möglichkeit, mit Hilfe des XPS einen Filter für irrele- 
vante Werte zu konstruieren, würde den Rechner dabei vor allzu großen Datenmengen 
bewahren. 

3. Man könnte einem entsprechend qualifizierten Benutzer einen manuellen Eingriff zu 
definierten Zeitpunkten erlauben, um etwa auch Auswirkungen motnentan als sehr wahr- 
scheinlich erachteter Störungen mit zu berücksichtigen, die aus Systemsicht nicht 
erkennbar sind. 

4. Eine weitere Erkenntnis der Untersuchungen ist die, daß man auf längere Sicht von der 
Idee getrennt operierender Z und A abrückt und mehr zu einer Kooperation zwischen den 




162 



beiden Programmen gelangt. Dabei soll nicht die Eigenständigkeit der Systeme zugun- 
sten einer abergreifenden Halle aufgegeben, sondern die Möglichkeit zur Kommu- 
nikation geschaffen weiden. Konkret geht es hier vor allem um die Idee, dem Abgangs- 
system als zentraler Auswertekomponente zu eriauben, weitere Simulationsläufe anzu- 
stoßen, falls bisherige Resultate noch keine hinreichende Signifikanz aufweisen. Sollte 
auch dann noch keine Entscheidung möglich sein, könnte schließlich durch Z der Bedie- 
ner selbst um die benötigten Informationen ersucht werden. 

Freilich soll das Grundkonzept unverändert bestehen bleiben. Ausgangspunkt ist nach 
wie vor der bereits «stellte XPS-Simulations-Kem. Die zusätzlichen Ideen lassen sich 
wahrscheinlich im Laufe der 2^eit als eigenständige, ab« ineinand«gieifende Module um 
diesen Kern gruppieren, so daß sie dessen Funktionalität anreichem. 

Betrachtet man nun alle Komponenten von SIMULEX im Überblick, so hat also die Arbeit an 
dem Projekt insgesamt die Migration des Erscheinungsbildes vom Ausgangszustand Abbil- 
dung 18 zum Zustand in d« Abbildung 24 bewirkt Dabei ist letzteres freilich als ein langfri- 
stiges Ziel anzusehen. Es muß sich im Zuge des Projekts zeigen, welche Ideen dieses 
Abschnitts teilweise od« ganz in den Prototypen eingefiigt iverden können. 
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Abb. 24: Mögliche Ausbaustufe von SIMULEX 
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1- Entstehung des Verfahrens 



Das EES geht aut einen Prototypen zurück, den die TU Berlin in Zusam- 
menarbeit mit dem SIEME“NS-Lei teinkaut aut EMS5800 entwickelt und 1906 
unter dem Namen BELI (Bauelemente-Lei teinkauts-In tormat ionssystem) 
veröttent 1 icht hat« 

Dieser Prototyp wurde bei SIEMENS wei terentwickel t und teilweise 
(Baustein " Ver tei lungsrechnung ” ) im Leite in kaut produktiv eingesetzt« 

Beit Antang 1989 wird das Vertahren aut SINIX neu entwickelt« Dabei 
wird das bisher in LISP und LÜDPS geschriebene System in LISP-KCL 
unter Einbeziehung der Ertahrungen des Produkt i veinsatzes und neuer 
Antorderungen nachgeb i Idet . Die erste, noch leicht abgemagerte SINIX- 
Version des EES wurde gerade ter t iggestel 1 t « 



2. Das fachliche Problem 



Einkäufer in einem Gro/l.unternehmen stehen vor einem mehrfachen Pro-“ 
b 1 em s 

• Bei vielen Einkautsentscheidungen sind eine mehr oder weniger gro4© 
Anzahl von Kriterien zu. ber ücksicht ig.e!"j , die das. Pi‘'o.d.u.k t , dei”» Her- 
steller oder das bstr« Marktsegment bet retten können« Nur bei "Sem- 
melware" kann es u.U. genügen, lediglich aut den Preis zu schauen. 

« Die Einkautsentscheidungen müssen oft unter einem massiven Zeitdruck 
gefällt werden« Dabei kann leicht der überblick ver lorengehen « 

, In jeder Verband lungsphase mujl nicht nur das eigene Interesse, son- 
dern auch das des Verband lungspar tners bedacht werden« Das Gesamtpa- 
ket mu(l auch für diesen interessant sein« 

. Der Blick des Einkäufers ist weitgehend in die Zukunft gerichtet; 
daher bietet eine "konventionelle" EDV-Landschatt oft keine oder nur 
eine unvollständige Datengrundlage für seine über legungen - 
« Eine einzige nicht optimale Einkautsen tscheidung kann das Unterneh- 
men zig Milli on ei“i DM kosten « 



Hier will das EEB Hilten bieten, die im Laute der Zeit immer mehr von 
der komplexen Einkautsprob lemat i k erfassen werden. 
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3. Charakterisierung des Verfahrens 



Das EES unterstüts: t den Einkäufer einerseits bei der kc3nkreten Vorbe- 
reitung, Durchführung und Auswertui'ig von Verband lungen mit den Liefe- 
ranten, und andererseits bei der vor weg nehmen den Betrachtung zukünfti- 
ger Mar ktgegebenhei ten . 

Das System ist in der Lage, Model 1 rechnungen durchzuf (ihren , bei denen 
wichtige Aspekte der Einkaufspolitik ber ücksicht igt werden« Grundlcige 
dieser Rechnungen können Daten aus vorgelager ten Verfahren, aber auch 
interaktiv eingegebene Simulations- oder Zukunftsdaten sein» 

Die Ergebnisse einer EES-Sitzung sind stets als Vorschläge an den 
Einkäufer gedacht, die dieser vor dem Hintergrund seines das Exper- 
tensystemwissen übersteigenden Einkauf swissens beurteilen und ggf- 
durch Simulation von Alternativen erhärten bzw, kreativ abändern soll- 
te« Dabei unterstützen ihn die teils verbale, teils graphische Erklä- 
rungskomponente und der weitgehend anwendergesteuer te Dialog des EES 
mit vielen Simulations-, Merk- und Rücksetzmöglichkeiten« 

Der Einkäufer bekommt so die Möglichkeit, seine Entscheidungen zu ob- 
jektivieren, zu dokument ieren und nachvol 1 z iehbar zu machen« Finanzi- 
elle Konsequenzen versch iedener Einkauf sst rateg ien werden sofort 
sichtbar « 

Das EES stellt Einkauf sentscheidungen auf eine solidere Grundlage« Mit 
gröiler'er Wahrscheinlichkeit werden Symptome und ihre Zusammenhänge 
schnell erkannt, besser gedeutet und in Verband lungsstrateg ien umge- 
setzt« 

Der EES-Einsatz ist sowohl für ein einzelnes Werk als auch für einen 
mehrere Werke vertretenden Leiteinkauf einsetzbar« 

Das EES ist sprachneut ral programmiert und kann daher ohne neuen Pro- 
grammierauf wand im In- und Ausland eingesetzt werden. 
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4. Methodenwahl - die Bretchen-f rage? 

D a B E" S i B i: a 1 si Ei! p e r' ± 0 n s y s 1 : b m 0 i"i ± s t a ri d 0 r« » S p ä 1 0 s 1 0 i"f b b 0 i d 0 E !•' 1 ä u i; 0 - 
r'urig der Opt imierung (siehe 6 ,. 1 m 2 »" 7 ) wird jedoch der Einwcind kommen, 
d a (l h i B r d o c hi b i ri ± y p i s c h 0 b G p 0 r a ± i o ri s ••••• R e s 0 a i" c: h P r o b 1 e m v o r 1 i 0 g t u. ri d 
daher eine üR-dlethode voi" 2uz i eben gewesen sei. Daher sollen hier eini- 
ge (Sedan ken 2’;ur Methoden wah 1 vorausgesch ickt werden, ohne in eine um-- 
a s s 0 ri d 0 D i s k u s s i o i"i d i 0 ss e r F“ r a g e b i ri t r' 0 t b i"i z u k ö i“i ri e r i „ 

Z i.i i"i ä c h B ± B o 1 1 ± e c:i a s M e i: h o d e n p i"- o b 1 e (n n i c h ± v 0 r k ü r z t g e s e hi e n wer' d e ri , 
den i-i bei d 0 r' ED V-E:!i"i t w i c k 1 un g sp i e 1 e!"i v i e 1 0 F"a k t o r' eri e i n e Fi'o 1 1 e , voi"i 
d e n e i"i h i e i ' i'i u i" e i i-i i g e g 0 n a r’i ri 1: s e i i"i s o 1 !L 0 n , d i e a b 0 r a 1 1 0 R ü c; k w i r' k i.u"i g e ri 
a L.t -f d i 0 M e? t h □ d 0 n w a h 1 l"i a b 0 i"i k ö i"i ri 0 i-i 5 

„ V e f ü g b a r k e i ± v o n R b c. h ri 0 r' r i 

„ A k t u 0 1 1 e B K i"i o w H o w d e r' E r i t w i c !•=: 1 u n g s - 1.1 n d d 0 1 ' W a r' t u n g s m a i-i r-i s c l”i a -f t 

» EI D V V 0 r B t ä !"i d n i s der A n w 0 n d 0 r' 

.. K o fn -f o r ± u i"i d L e i s t u i"i g s g r' e n z e ri v e i" -f ü g b a r 0 r EI n 1 : w i c: k. 1 n n g s u m g b fo u n g 

« Stär k 0 i"i u i-i d Sc h wache i"i v 0 r f ü g fo a r er P 1 - o g \" a m m i e r s p r' a c h e? ri 
„ l< o m -f o r - 1 Li i"i d L eist u n g b g i' e ri z b ri v e» r t Q g b a r Ei \" A bla u f u m g 0 b la ri g 
.. G i" a p h i k m ö g 1 i c h k 0 i t e ri v 0 r t ü g b a r 0 r' F\’ e c h i“i e r 

D i 0 Ul i c h t i g k e i t d e s Wortes " v e r f ü g b a r' ' ' e i" g i b t s i c h a la b d e r T a t s a c h 0 , 
d a {I EI D V ••••• Ei i"i t w i c k 1 la ri g e? r» d e I i"i d la b t r- i e m b i s t u i"i t e r z w i n g e i"i d e ri R e ri t a b i 1 i - 
tätsigE^sichtspLAnkten in einsam gE?gebenE?n admin istrat i ven , maschinellen 
u I'I d m 0 n B c: h 1 i c h e i-t R a h 0 ri s t a i: 1; f i i-i ä e ri » Z i e 1 d e s P r o .j e k. 1 1 0 i t b r s i s i: 0 s 
z LA i"! ä c h B t , LA i"i t E? i- d 0 Pi ge? g b b e? i“i e? n B e d i n g la ri g e ri d i b b e s t m ö g 1 i c h e? E n t w i c k -• 

1 u n g B - u ri d Ablauf u m g e b la ri g z u wähle i“i , die s C3 w o h 1 d i e a k i: la e 1 1 e? EI i-i t w i c k - 
iLAng LAnterstütz t , als aLAch den Weg zla absehbaren Wei tE?rei-itwick iLArigen 
□ t-f enhäl t « 

N a c hl der' Wahl der Li m g e? b la n g s t eilt s i c t? d i b F" r' a g e d e? r a n z u w e ri d e? ri d e i”i 
Methoden luü. schon in erigerem Fl'ahmen, sollte in komplexen Systemen 
aber tür jeden in sich gesch lossenen Bausteiri neu gestcallt werden. 

E i ri e b es t i mm t b Lirng E?fo un g sch 1 i ef.^ t nicht n o t g ed i' uri g eri Me t h od en auc h 
t !•' e m d 0 1 -' Fi e 1 ' k la ri f t a li s . ( M i c h t 'v' e r g e s s e r i wer d b ri sollte?, d a ß -• g a ri z n e - 

benbei -• ein groj^er Teil En twick lungsautwandes von methodologisch 

un p r ob 1 ej ma t i sc h en , oft k on ven t i ori eil z u p r og i' amm i e r ei”i d eri F\’ou t i i"i eri z u r 
U ri 1 0 )•' B t ü t z u i"i g d e s A r i w e? ri d e r d i a 1 o g s , der B e d i e ri u r i g d e r G r a p h i l-:; o fo e i ' 1 1 ä - 
che, der Daten- Lind Tei 1 nehme rverwal tui"ig u.a. vereinnaihmt wird.) 
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Beim EEB wurde eii'ie Elxper-tensystemumgebung gewählt, weil von An-fang an 
ab seh b a !•' war, d ai'l ri i c h t a 1 1 e E i ri kau -f sp r' ob 1 eme m i t " k oi-i veri t i oi“i e 1 1 eri " 

Mittel ri gelöst we r d eri k on n t ei'i , ui"i d weil ei n e so 1 c h e Umgeb un g 

wei t er führende Mög 1 ichkei ten bietet, d»h. "nach oben offen" ist. Im 
e i i"i z e 1 i“i ei"j b o t eri s i c h ri oc h e i ri e Re i h e von Vo r t e i 1 eri , w i e im we i t e i' ei-i 
g e z e i g t we r d e ri w i i-' d . 

Die haup tsäch 1 ichen derzeit benutzteri Techniken sind folgende: 

, ob jektor ient ier te F-'rogi'ammierung 
. r B !•:: u )•' s i v e L. i s t e i"i v e i"- a i-' b e i t i..i i"i g 
. vo r wä r t sg e r i c h t e t e F\'eg e 1 i ri t e i-' p r e t a t i oi"i 
.. 0 p t i m ;i. e r u ri g s h e u r i s t i k 

Bei den betr« E."ES~Bausteinen wird hierauf noch einmal eirigegangen wer- 
den » 

Grundlage der Elntwick lung des EEIS war und ist eine enge Zusammenarbei t 
m i t me h r e r e ri E i n !•:; a u f s a b t e i 1 u r'i g e ri ( l... e i t e i i"i k auf i.i i"i d W e i" k' e ) , um das E - 
pertenwissen auf dem Rechner abbilden zu können. Ein wichtiges Problem 
hierbei liegt in der Verstand igung zwischen Anwändern und Entwicklern« 
Diese wird dadurch sehr erleichtert, da\fl die Expertensystemumgebung es 
gestattet, die Prob lemstel lung weitgehend konkret-f achbezogen , statt 
abst rakt-mathemat isch , zu formulieren und auf dem Rechner zu modellie- 
ren« Die Schwier igkei ten mit der Akzeptanz komplexer OR~Modelle bei 
vielen Anwendern sind bekannt; OR-Heur i st i ken bieten sich oft als Aus- 
weg an (cf- 2 IMMERMANN p. 250). 

Nicht alle Einkauf sprob lerne lassen sich auf Zahlen reduzieren. Bereits 
urisere Er f ah i'ungen mit dem Prototypen der Z i e 1 p) r e i ser m i 1 1 1 urig (siehe 
6.2) haben gezeigt, dajl wir im EES mit Fragestellungen konfrontiert 
werden können, die nur auf fachlich bezogener Symbol ebene zu formulie- 
ren sind- Eine Exper tensystemumgebung ist hierfür prädest in ier t . 

Elinen gro/3en Vorteil bietet auch das ob jektor ient ier te Programmieren 
in einer Expertensystemumgebung, da es aufgrund der von ihm geförder- 
ten Modular isierung des Systems vielfältige Möglichkeiten bietet, mit 
"rapid prototyping" dem Anwender einen unmi t telbaren Eindruck von den 
Auswirkungen seiner Anderungswürische zu vermitteln, ohne das Gesamtsy- 
stem zu gefährden. 

Mögliche Gefahren bei einer solchen Vorgehensweise sind folgende: 
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- Bei komplexeren Ver -fahren ist der entstehende Prototyp o-ft insgesamt 
nicht optimal- Man muß dann zu einem günstigen Zeitpunkt den Mut ha- 
ben, das Gesamtsystem neu zu konzipieren« 

« Die angewandten Methoden können, müssen aber nicht in ein schlüssi-”- 
ges mathemat isches Modell passen; die ge-fundenen Lösungen sind daher 
u«U. zwar sehr h i 1 -{ü'eich , a\ber nicht Zwingendermafien optimal« E^ei 
Heuristiken ist dies regelmäßig der Fall, sowohl im Operations Re- 
search als auch bei Expertensystemen» Aufwand und er -forder 1 iche Güte 
der Lösungen sind gegeneinander abzuwägen. 

Zwischen Expertensystemen und Operation Research sollte man keine un- 
nötigeri Grenzen ziehen. Heuristiken werden z-B-, genau wie Entschei- 
dungsbaum- und manche stochast ischen Ver-fahren, von beiden angewcind t . 
Wenn auch technische Mittel, Modellierung und Formulierung bei beiden 
Richtungen typische Schwerpunkte haben, können beide doch Zusammenar- 
beiten, sich ergänzen und voneinander lernen« 

Das E"ES setzt au-f einer Expertensystemumgebung aut und wird deren 
technische Möglichkeiten mit der wachsenden Komplexität der behandel- 
ten Einkautsprob lerne in immer stärkerem Maße nutzen. Je nach Baustein 
kommen verschiedenste Methoden zum Einsatz- Auch die Option der Anwen- 
dung von Operat ions-Research-Methoden wird ottengehal ten « 



5. Architektur und Systemstand 

Die Konzeption des EEB geht von drei Bausteinen aus: 

. Verteilungsrechnung 

Dieser E^austein enthält die Errechnung und Ausgabe von Vertei- 
lungsmatr i zen über eine variable Anzahl von Werken und Herstellern 
je Produkt, die dazugehörigen Kumul ierungsstuten und Herstel lerpa- 
kete samt Simulationsmöglichkeiten und Er k lärungskomponen te« 

Er wurde bereits auf EMS5800 produktiv eingesetzt und steht seit 
1 0 « 90 auc h au-f MX 300 un d MX 500 z u r Ve r -f üg un g « 

. Zielpreisermittlung 

Dieser Baustein enthält die Errechnung von Zielpreisen, die Durch- 
■führung der Ver tei lungsrechnung au-f Basis der Zielpreise und die 
ei'i t sp r - Er k 1 ä i-' un g s k omp ori en t e . 
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Er ist ier t au-f EMS5S00 als Proi;otyp und wird 1990 -Für SINIX neu 

k oi"i z i p i e r' i: » 

. Strategiebaustein 

Dieser Baustein wird alle strategisch ausger i ch teten Werkzeuge 
enthal ten . 

Termine tür die Konzeption dieses Bausteins liegen noch nicht vor- 



6. EES-Bausteine 



6.1 Verteilungsrechnung 



6.1.1 Funktion 



Ein Vorschlag zur Volumen- und Mengenver tei lung wird au-f der Grundlage 
der (realen oder -fiktiven) Werksbedarfe und Herste 1 1er angebote errech- 
net, und zwar entweder -für ein einzelnes Produkt oder -für alle Produk- 
te einer Kumulierungsebene, Im letzteren Fall werden die Kumulierungen 
über alle Ebenen bis zur verlangten mit errechnet und können beliebig 
abgeru-fen werden. Mögliche Kumulierungsebenen: 

« Mater ialgruppe (z.B. IC) 

. Pi'oduk tgrupp)e (z.B. Speicher) 

« Pr oduk tun ter gruppe (z.B, DRAM) 

Das Ergebnis wird in einer Matrix aut dem Bildschirm ausgegeben. Nähe- 
res hierzu wird unter 6. 1.2,8 beschrieben. 
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6.1.2 Vorgehen der Verteilungsrechnung 



6.1.2. 1 Wahl des Szenarios 



Vor der ersten Auswahl fragt das EES ggf- zurück, was mit bereits er- 
arbeiteten Szenarien geschehen soll- Der Einkäufer kann sie löschen, 
stehen lassen , in die Grunddaten übernehmen oder unter einem frei ge- 
wählten Namen in einer Datei spe i ehern - 

Der Einkäufer gelangt über, eine Menükaskade, die mit der obersten Ku- 
mulierungsebene beginnt, zu der gewünschten Ebene- Er kann ein F'rodukt 
auch direkt anwählen- 

Nach der Wahl des Produktes bzw- der Kumulierungsebene geht die Ver- 
tei lungsrechnung in folgenden Schritten vor sichs 



6. 1.2.2 Strategieeingabe 



Zu jedem Hersteller kann neben dem Preis die Bewertung seiner Quali- 
täts- und seiner Log ist i k leistung vor liegen. Diese drei Kriterien kann 
der Einkäufer produk tbe?ogen prozentual gewichten- Er kann so auf kon- 
trollierte Weise von einer rein preisbezogenen Betrachtung abrücken, 
seine Entscheidung durch simulative Gegenüberstellung alternativer Ge- 
wichtungen untermauern und jeweils die f inanz iel len , qualitativen und 
logistischen Auswirkungen auf zeigen- Die gewählte Strategie wirkt sich 
bei der Zielmengenermittlung aus (siehe 6- 1-2- 5). 



6. 1 . 2. 3 Lieferantenbewertung 



Alle Hersteller, von denen ein Angebot zum aktuellen Produkt vor liegt, 
werden gemä^ ihrer Preis-, Qualitäts- und Log ist i k leistung bewertet- 
Diese Bewertung wird zunächst für jedes Kriterium getrennt als Faktor 
im Verhältnis zum jeweils besten Hersteller ausgedrückt- Dadurch wer- 
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den nichi: die absoluten Werte, sondern aussch 1 iei3 1 ich die Bewertungs- 
untersch iede ber ücksicht igt . 

Ansch 1 iejlend werden die Einzelbewertungen -für jeden Hersteller zu ei- 
ner Gesamtbewer tung zusammengef ai3 1 . Hierfür stehen zwei Optionen zur 
Auswah 1 ! 

Arithmetisches Mittel 

Hiermit werden ausgeglichene Ergebnisse erzielt, da ein in einem 
einzelnen Kriterium vielleicht vor 1 iegender positiver oder negati- 
ver Extremwert durch die anderen Kriterien nivelliert wird- 

. Raumdiagonale 

Hier gibt bei jedem Hersteller das beste Einzel kr i ter ium den Aus- 
schlag, da die Länge der Raumdiagonalen des Quaders, dessen Kanten 
durch die drei Bewer tungskr i ter ien gebildet werden, den Wert des 
besten Kriteriums nie unterschrei ten kann. 

Die ausschl iefll iche Berücksicht igung der Bewer tungsuntersch iede hat 
zur Folge, 

. da/1 alle Kriterien miteinander vergleichbar werden, 

. dai^ unterschied! iche Bewertungsskalen zu verg leichbaren Ergebnis- 
sen führen, 

. daj^ das System seinen Mengen vor sch lag für den einzelnen Hersteller 
automatisch an die jeweiligen Marktgegebenhei ten , d-h. die Bewer- 
tungen der ber ücksicht igten Mitbewerber, anpai^t- 

Die Größe des Bewer tungsuntersch ieds bestimmt so primär den vorge- 
schlagenen Volumenunterschied zwischen zwei Herstellern. 



6. 1 . 2. 4 Lieferantenauswahl 



Ausgewählt wird eine bestimmte Anzahl von Herstellern, wobei vom be- 
sten zum schlechtesten It. Lief erantenbewer tung (siehe 6- 1.2.3) ge- 
zählt wird. Die Anzahl der ausgewählten Hersteller hängt vom Bedarf 
des jeweiligen Werkes ab, um die Versorgungssicherhei t zu gewährlei- 
sten, Diese Abhängigkeit kann in Vertei lungsregeln festgelegt werden, 
die verschiedenen Gr ößenordnungen von Bedarfsvolumina eine verschiede- 
ne Anzahl von Lieferanten zuordnen, z.B.: 
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mehr als 
mehr als 
mehr als 
meh r als 



0 DM 
20.000 DM 
200-000 DM 
000.000 DM 



1 L ie-ferani: 

2 Lie-f eran ten 

3 Lie-ferai’i ten 

4 Lieferan ten 



In Zusatzregeln kann bestimmt werden, dai3 unter' gewissen Vorausset Zun- 
gen (z.B. Preis nicht mehr als 27. höher als der letzte ber ücksich t ig- 
te) auch der e^rste nicht mehr berücksicht igte Hersteller noch hinzuge- 
nommen wird. 



Die Ver tei lungsregeln können hierarchisch -für alle Kumul ierungsebenen 
und einzelne Produkte de-finiert werden. Das EE!£) wendet in jedem Ein- 
zel -fall die spez i t i schste zutre f t ende Regel an- Hierarchisch tie-f er- 
stehende Regeln haben daher die Wirkung von Ausnahmen zu eil Igemeinereri 
Regeln . 

Die Abarbeitung der Regeln geschieht rein 'vorwär tsger i ch tet (torward 
reasoning) . 

Ein Problem besteht darin, dai^ die Ver tei lungsregeln sich au-f das 
Werksvolumen beziehen. Dieses hängt jedoch von den ausgewählten Her- 
stellern, ihren Preisen und ihren Zielmengen (siehe 6. 1-2.5) ab- Eine 
saubere Volumensermittlung würde daher mehrere Durch läute mit allmäh- 
lichen Annäherungen ertordern. Da eine absolute Genauigkeit von den 
vor aus zuseh enden Gr öflen Ordnungen her jedoch irrelevant ist und bei 
Verhandlungen er tahrung sgemä(3 die niedrigeren F^'reise die Richtung an- 
geben , wird hier au tg rund des Werksbedarts und des Durchschn i t tsprei- 
ses der beiden besten Hersteller ein "theoretisches Ver tei lungsvolu- 
men" errechnet und danach definitiv ''/erteilt. 



6. 1.2.5 Zielmengenermittlung 



Die Lieterantengesamtbewer tung wird für die ausgewählten Hersteller in 
eine "ideale" Ver tei lungskurve aut Volumenbasis umgesetzt; "ideal" 
deshalb, weil keine der in der Praxis ott vorliegenden Restr i k t ionen 
(siehe 6- 1.2.6) ber ücksicht ig t wird. 




176 



Zusätzlich zu den E-Jewer tungsuntersch ieoden wird hier ein Stel 1 -f cxktor 
ber ücksicht igt , mit dem der E'inkäufer die It» Lie-f erantenbewer tung 
besseren Hersteller gegenüber den schlechteren bevorzugen kann:: 

. Faktor 1: lineare Verteilung It« Bewertung 

. Faktor 1,1s 10% Zusatzvor tei 1 über den Eisewer tungsvor tei 1 hinaus 
. Faktor 2s Verdoppelung des Bewer tungsvor tei Is , usw.. 

Da sich diese überpropor t ionalen Volumensvor tei le kumulieren, entsteht 
eine zu den besseren Lie-f eran teri hin immer steile^r- ansteigende Vertei-”- 
lungskurven v3e grö(3er der Bewer tungsvor' tei 1 eines Lie-feranten gegen- 
über den weniger guten ist, desto mehr profitiert er von der Kurvern™ 
überhöhurig - 

Die Ideal ver tei lung ist die Zielvorgabe -für die Lie-fermengenermi 1 1 lung 
(siehe 6,1 »2, 6) und die Optimierung (siehe 6. 1.2. 7) und ein Ansporn 
-f ür den EI i n kauf er , vor 1 i egende F\'es t r i k t i onen aut i h re Berech t i gung zu 
h in ter tragen. Sie geht auch in die graphische Erklärung der Ziel mengen 
ein (siehe 6. 1.5.1). 



6. 1.2.6 Liefermengenermittlung 



Die "ideale" Verteilung wird nun ggt, autgrurid der vorliegenden Re- 
striktionen moditizierts 

. fehlende Freigaben in einzelnen Werken 

Für jedes bet rot tene Werk wird eine neue Zielmengenermittlung un- 
ter Ausschlu/1 der nicht t reigegebenen Hersteller durchgetührt; da- 
durch erhalten u.U. auch bisher nicht ber ücksicht igte Hersteller 
eine (interne Ziel- und) Lietermenge. 

. vor geschriebene Höchstmenge je Hersteller und Werk 

Falls die Höchstmenge überschr i t ten ist, wird die überschüssige 
Menge anderen Herstellern im selben Werk proportional zu ihren 
Zielmengen zugeteilt, soweit dort keine Rest r i k t ionen dagegenste- 
hen. 

. vorgcschri ebene Mindestmenge Je Hersteller und Werk 

Falls die Mindestmenge nicht erreicht ist, wird die fehlende Menge 
bei anderen Herstellern im selben Werk proportional zu ihren Ziel- 
mengen weggeholt, soweit dort keine Restriktionen dagegenstehen« 
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Beispiel eines Produktszenar ios mit Standardstrategi 
(P = Preis, Q = Qualität, L * Logistik) 
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allgemeine Mindestmenge 

Im EES ist eine allgemeine Mindestmenge festgelegt (derzeit 5"/» vom 
Werksbedar f ) , die bei Einkäufen je Lieferant nicht unterschr i t ten 
werden soHte» Falls diese Mindest menge nicht erreicht ist, wird 
die fehlende Menge bei anderen Herstellern im selben Werk propor- 
tional zu ihren Zielmengen weggeholt, soweit dort keine Restrikti- 
oi"i ei”i en t g eg eri s t eh eri « 

Bei ausgeschal teter Optimierung (siehe 6. 1-2.7) bilden die Ergebnisse 
der Liefermengenermi ttlung die Grundlage eines Szenarios, das in einer 
Matrix auf den Bildschirm ausgegeben werden kann (siehe 6. 1.2.8). 



6. 1.2.7 Optimierung über alle Werke 



Bei Vorhandensein mehrerer Werke kann optional eine Optimierung über 
alle betrachteten Werke durchgeführt werden. Dies ist immer dann sinn- 
voll, wenn man im Sinne einer Leiteinkaufsidee das Interesse der 
Werksgemeinschaf t als ganzer ber ücksich t igen will. 

Das EES führt zur Optimierung eine Z ielmengenermi tt lung (siehe 
6.1.2.5) über alle Werke durch, wobei es sämtliche in wenigstens einem 
Werk ausgewählten Hersteller berücksicht igt . Ansch 1 i eilend versucht es, 
durch Umverteilung der Liefermengen, auch über die Werksgrenzen hin- 
weg, diese Zielmengen trotz der Restriktionen zu erreichen- Hierbei 
wird der E<edarf der einzelnen Werke nicht angetastet, und alle etwai- 
gen Umschichtungen werden in einem ausgewogenen Verhältnis zu den 
Werks- und Herstel 1er z iel mengen vor genommen, um kein Werk im Interesse 
der Werksgemeinschaft unverhäl tn ismä/2 ig zu belasten. 

Der Einkäufer kann ggf. mithilfe des EES simulativ Werks- und Gemein- 
schaf tsinteresse gegenüberstel len und so Entscheidungen vorbereiten. 

Bei der Optimierung wurde auf den Versuch der Ausarbeitung eines 
durchgängigen mathematischen Modells im Sinne des Operations Research 
zunächst verzichtet« Damit wurde die Linie des von der TU Berlin er- 
stellten Prototypen fortgesetzt. 

Mit den Zielmengen je Hersteller über alle Werke gibt es je Hersteller 
eine anzustrebende Zielvorgabe. Diese ist allerdings auch über alle 




181 



Werke hinweg nichl: immer erreichbar; Überschüsse bzw. Unterdec kungen 
müssen gg-f. proper t ional verteilt werden. 

Kern der Optimierung ist eine Routine, die die Abweichung der Lie-fer-- 
menge eines Herstellers von seiner Zielmenge -feststellt, diese propor- 
tional aut seine Lietermengen in den einzelnen Werken verteilt und den 
(Begenwert bei anderen Herstellern jeweils im selbc^n Werk proportional 
ablietert bzw» abholt« Falls nicht alles abgeholt bzw. abge liefert 
werden kann, werden die Restabweichungen bei den Werken un ter zubr ingen 
versucht, bei denen noch kein Stop Zeichen gesetzt wurde. Wenn alle Ab- 
weichungen beseitigt bzw. alle Werke "Stop” gemeldet haben, ist der 
Durchlauf für den betr. Hersteller beendet« Da das Ab liefern bzw. Ab- 
holer» rekursiv durch dieselbe Routine geschieht, ist die dauernde Kon- 
sistenz der Datenmatrix und die wer ksübergrei f ende Optimierung auch 
der gerade nicht aktuellen Hersteller im Prinzip gewährleistet« 

Komp 1 i z ier ter wird das Vorgehen dadurch, 

« darl durch enge Restr i k t ionen die anv isi er ten Zielmengen u.U« nicht 
erreicht werden können, also nach wei testgehender Annäherung noch 
ein verb leibender (positiver oder negativer) Afoweichungsrest pro- 
portional verteilt werden muj'i , 

. da(l der aktuelle Hersteller automatisch Opt imierungspr ior i tät hat 
und so bei sequentiellem Durchlaufen der Herstel 1er 1 isten alle nö- 
tigen Mengen an sich ziehen und alle seine Zielmenge übersteigenden 
Mengen von sich weisen wird (also: wer sich zuletzt bedient, ist am 
besten bedient) 

« da(^ eine späte Op t imierungspr ior i tät sich in den Fällen in ihr Ge- 
genteil verkehrt, wo sehr enge Rest r i kt ionen bei den ai'ideren Her- 
stellern seine Verteil- bzw. Abholanf orderungen ganz oder teilweise 
vereiteln (also: wer sich zuerst bedient, ist am besten bedient) 

Die aktuelle EES-Version arbeitet mit einer Kombination von Vorwärts- 
und Rückwär tsopt imierung und, bei Bedarf, einer propor t ionalen Schlui3- 
verteilung von Überschüssen vom schlechtesten Hersteller aus. Diese 
Vorgehensweise liefert in real ist ischen Situationen von der Zielset- 
zung her je nach Komplexität der Situation brauchbare bis optimale Er- 
gebnisse und kann bei Bedarf noch verfeinert werden. 

Nach den Erfahrungen des demnächst an laufenden Pilotbetriebs wird dar- 
über zu entscheiden sein, ob es möglich, notwendig und vom Aufwand her 
vertretbar ist, die Optimierung mit Operat ions-Research-Methoden in 
ein mathematisches Modell zu kleiden. 
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Beispiel einer Produkmatr ix bei Standardstrategie 
mit vor geschriebener Höchstmenge (ANTON in Trudering), 
vargeschriebener Mindestmenge (BERTA in Laim) und fehlender 
Freigabe (DORA in Trudering) 



























P/S-Szenario 

Produkt (RT> iAHTOII 1 |»ORA 2 1 BERTA 3 1 CAESAR « 

•RAMNX1/S0J-7B iS »N 21 M 16 »N 18 »N 
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Stückzahlmatrix zu vorstehendem Szenari 
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6. 1.2.8 Szenarienerstellung und -ausgabe 



Die Rechenergebn isse werden in einem Szenario zusammengef ajl t und als 
Ve I' i: e i 1 uri g sma tri x au f d eri B i 1 d sc h i r m ausg eg eb eri « £ie i Kumu 1 i e r un g eri 
wird die erste Bi Idsch i rmsei te der Matrix der höchsten verlangten Ebe 
ne ausgegeben; alle anderen E"r gehn isse können durch Blättern bzw« Me- 
nüauswahl abgeru-fen werden. 



6.1.3 Alternative Szenarien 



6. 1.3.1 Kostenszenario 



Nebel"! dem i ' eis k ö n i"i e n e i i"! e m S z e i"i a r i o a u c h Q u a 1 i t ä t s k o s i: e i"i u n d L o g i 
stikkosten zugrundegelegt werden. Das EES bildet dann die Summe aus 
Preis und Kosten und legt diese als Preiskr i ter ium der Verteilungs-" 
rechnung zugrunde. Ansonsten läu-ft die Verteilung ab, wie untei-' 6.1.2 
beschr ieben . 



6. 1.3.2 Stückzahlszenario 



Aut der Produktebene kann zu jedem Preis- oder Kostenszenar i o das ent 
sprechende St ückzah Iszenar io abgeruten wer den - 



6. 1.3.3 Interaktive Szenarienänderungen 

Jedes am Bildschirm ausgegebene Szenario kann interaktiv in vieltälti 
ger Weise verändert werden. Diese Änderungen können Parameteränderun- 
gen, Datenkor rek turen und -neueingaben oder aber Simulat ioneri sein 
(Was-Wenn-Szenar ien) « Demen tsprechend werden sie grundsätz 1 ich in ei- 
ner Kopie der Grunddaten durchgetührt und werden nur aut Antorderung 
des Einkäuters in die originalen (geladenen) Grunddaten des EES einge 
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•t r' a g e ri - Sie l-:; ö n n e n , u ,, U « r \ a c h A r' c h i v i 0 1 " e? i*! i n ei ri 0 1 -' D a t ei o d e i"- A u s -- 

d !•' u c k e !“i , j e d eo i' zeit w i e d e? 1- v e v' w o r' -f e ri wer' d 0 ri « 

F' ü l g 0 ri de A i"i d &? r u i"i g liä ni ö g 1 i c: h k 0 i t e n s i i"i d '•/ d v' g e b e h e n s 

A i’i d 0 r u i -i g d 0 r' S t r a ± e g i e ( K r i 1 0 r i 0 ri g 0 w i c h t u ri g ) 

. A i'i d 0 r Li I"! g d 0 s A .1 g a i" i t h m u s d 0 1 ' L. i 0 -f 0 1 ' a i'i t e n g 0 s a m t b 0 w r i: l.i ri g 

n A i"i d 0 r' i.i i“i g d 0 s B -t 0 1 1 f a l-;: t. a r s i ü r- die V 0 r 1 0 i 1 i.i n g s k li i" v 0 

.. L ö B c h 0 i-i / M 0 u a li -f ri a h e '•/ an Wer k 0 i"i 

„ A ri d 0 1' u rt g d es Be d a r f s . j e Wer k 

» E i i"i 't !•' a g u n g 0 i i-i 0 1" -für' V e i-' h a i"i d 1 u n g 0 ri f r 0 i z u. h a 1 + 0 rt d e n M e ri g 0 

als F-rozerit vom ElJedari' 

. L. 0 B c Y) 0 n / Me u a u -f i'i a h m e v o rt hl 0 r' s 1 0 1 1 e r n 

.. F* r' 0 i B ä i"! d 0 !•' u rt g , j 0 H 0 r s 1 0 1 1 e? r 

. E i i"i 't r' a g li i"! g / A i'i d 0 r' li r i g d 0 1" Q u a 1 i ’t ä t b k o b t. 0 rt , j 0 H 0 r b t e 1 1 0 r 

. E i n ± r a g u i“i g / A n d e v' ix ri g d 0 1*' L o g i b ’t i k k o b 1 0 i'i .j 0 hie r b 1 0 1 1 0 r 

„ E i n 1 : r' a g l.i i-'i g / A i"i d 0 r' u rt g d 0 1" Q u a 1 i t ä t s b e w 0 r t li rt g j 0 h -1 e r b 1 ; eile i" 

« E i !"i t r- ag uri g / Art d 0 r ui"i g d 0 r- Log i b ± i k b 0 we t un g j b He i' s 1 0 1 1 e r- 
» F" !•' e i g a\ b 0 / S p 0 r' i' u ri g v o i-i H 0 r s 1 0 1 1 e r rt je Wer k 

« E; i i"i 1 : ragurig/ Ai"i der Lirtg einer Miridestmei'ige je Her'steller Lirid Wer'k 

als absolu-te Stückzahl oder als Prozent vom Wei'ksbedarf 
„ Eiritragung/Anderung einer Höchst menge je Hersteller und Werk 
als absolute 'Stückzahl oder als Prozer'it vom Werksbedar-f 
- £"ii"r-/ALisBchal teri dei" Optimier-ung über alle Werke 

„ Eirv-/Ausschal ten der Anzeige der Vorper i odendaten je Hersteller 

Alle Anderungeri können durch Ank licken der en tsprechenden Felder au-f 
der Ausgabemati'iK angesto(?'ei"i werden» Der Benutzer wird dur'ch feld- und 
si tuat ionsspez i -f ische Menüs geführt. 



6.1.4 Herstel lerpakete 

F-ür den Erfolg von Verband 1 ungen ist es wichtig, dem jeweiligen Her- 
steller ein für ihri interessantes Lieferpaket anzubieten. Daher kann 
dE?r Einkäufer im EES stets die "Gegenprobe" zu den von ihm erarbeite- 
ten Szenarien machen und sich das für einen Hersteller herauskommende 
F-'aket ausgeben lassen, FHierbei werden alle Datei-i bis zur gewählten Ku- 
muli er ungsstufe nach dem betr. Hersteller gefiltert und in einer Ma- 
trix ausgegeben. 
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6.1.5 Erk lärungskomponente 



6. 1.5.1 Mengenerklärung 



6. 1.5. 1.1 Zielmengenerklärung 



Das Zus-tandekommen der Zielmengen (d,h. der Mengen, die -für jeden Her- 
steller vom EES vorgesch lagen würden, wenn keine Restriktionen vorlä- 
g er» ) w i r- d g r ap h i sc h e r- k 1 ä i-' t - 

Drei Kurven zeigen aut, welche? Menge jeder Hersteller bekommen könnte, 



- wenn 


er 


nur nach 


seinem 


F'reis bewertet würde. 




- wenr» 


er 


nur na\ch 


seiner 


Qual i tätsleistung bewertet 


würde 


- wenr» 


er 


nur nach 


seiner 


Log i s t i k 1 e i s t ui-i g b e we r t e t 


wü rde« 



Schl ieill ich zeigt eine vierte Kurve, welche Mengen das EES unter E<e- 
r ücksich t igung aller drei Kriterien in der vom Einkäuter eingegebenen 
Gewich tung vor sch lägt . 



D i e s e E i' k 1 ä i' u r» g h i 1 1 1 dem Ei n }•:: ä u t e i-' b ei der F i i"» d u i“» g s e i i"» e r' p r o d u k t s p e - 
zitischen Verband 1 ungsst rateg i e ebenso wie bei der Argumentat ion ge- 
genüber Vorgesetzten und L i et er an tei"» . Die Situation des betr. Markt- 
se?gmei"ites urid etwaige Abweichurigei'i eines Herstel ler's hiervon, seine 
Btärkei’i ui"»d Schwächen tallen sotoi^'t ins Auge- 

Je nach Stellenwert der einzelnen Kriterien können er» tsprechende Ent- 
scheidungen vorbereitet wei-den„ Durch Durchspielen anderer Werte (sie- 
he 6n 1 , 3 , 3 ) ui"i d Ab r u t de r j e we i 1 i g er» Z i e 1 men g er» e r k 1 ä i*' ui“i g k ö r» n ei'i Alter - 
nativen autgezeigt, Folgen möglicher Verhandlungsergebnisse autgezeigt 
oder Anreize tür besondere Anst rengunge?n des Lieteranten gegeben wer- 
den , 
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Zielmengenerklärung bei Standardstrategi 
(Preis 50X, Qualität 25%, Logistik 25%) 
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Zielmengenerklärung bei Betonung der Qualitätsleistung 
(Preis 15%, Qualität 60%, Logistik 25%) 






VerteiLung der Liefe 
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6.1.5. 1.2 Liefermengenerklärung 



Die Grö|3e der Lief ermengeri eine<s Herstellers (d.hu der unter Berück™ 
s i c h t i g ui-i g alle i' Rest i" i k t i □!-) eri u!"i d g g t „ d e i' Gp t i m i e r ui“i g üb e i-' all© Wer 
k e V o r' g e s c: h 1 a g e n e n M e n g e i"/ siehe 6 „ .1. u 2» ) u ri d i h r e A u f t e i 1 u n g a li -f d i e 

beteiligt en We r k e w i i-' d als Säul en g r ap h i k d & r Ku i" ve d e r Z i e 1 mej"i gen 
(siehe 6. 1.2.5) gegeriübergeste^ll t . 

Ins Auge fallen sofort die Verbrauchsschwerpunk te ennes Produktes und 
etwaige über-- oder Untei'schrei tungen der Zie?lmengen axufgrund von Re- 
st r i kt ionen . 



6. 1.5.2 Erklärung der Lieferantenanzahl 



Diese 1< o m p o n e r-i t e i st i n der' E M S 5 8 0 0 -Fas s u ri g des E E S i p 1 e m e i"i t i e r' t u n d 
für die riächste SINI X-Version des EES ebenfalls vorgeseheri. 

Sie liefert verbale Erklärungen zur E<er ücksicht igung der Lieferanten. 
Ein Beispiel: 

Das Volume i"! des Wer' I-:; s Laim ü b e i' s t e i g t 2 0 0 . 0 C) 0 DM, a b e i' i-i i c h t 2 .. 0 0 0 „ 0 0 C* 
DM. Hierfür bräuchte es 3 Lieferanten. Es sind jedoch nur 2 L ief er an-- 
ten freigegeben- Diese sind Anton, Caesar und Dora. Die Freigabe von 
Berta sollte erwogen werden« 

Das Volumen des Werks Trudering übersteigt 2-000.000 DM. Hierfür 
braucht es 4 Lief erari ten . Die besten frei gegebenen sind Anton, Berta, 
Caesar und Dora. Der Lieferant Emil wurde nur wegen einer vorgeschrie- 
benen Mindestmenge ber ücksicht igt . 

Obiges Beispiel belegt, dafJ hier über die bio(3e Erklärung der Anzahl 
der Lieferanten der Weg zu komplexen Ei" k 1 ärungei’i eines Szei'iarios an ge- 
treten ist. 

Die Schwier igkei t dieser (wie aller anderen verbalen) Er k lärungskompo- 
nenten liegt in der sprachneutralen Programmierung » Wegen der untetr- 
schied liehen syntaktischen Strukturen der versch i ©denen Landessprachen 
mufl die bisherige, einsprachige Satzgener ierungsrout i ne erweitert 
werden. Aus Kostengründen scheidet jedoch ein Einstieg in die komple™ 
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xen linguistischen F-ragen eines (-für eine Anzahl Sprachen) allgemeinen 
Batzgener ierungsmodel Is von vornherein aus. 

Der EE"S-Ansatz geht von tolgenden pragmatischen Vorgaben auss 
„ Beschräi"ikung aut die Strukturen der groflen europäischen Sprachen 
. E^eschränkung aut die in der Er k lärungskomponente wirklich gebrauch"” 
t e n S a t z s 1 1 ' u k ± u r e ri 

. Verzicht aut F-"lex ionsgener ierung und Inkautnahme dadurch notwendi- 
ger Mehi'tacher tassLing von Wortstämmen 

Aut dieser Grundlage wird tür jeden vor kommenden Satz ein "sprachunab- 
hängiges" syntaktisches Modell erarbeitet, das alle vor kommenden (syn- 
taktischen) Varianten umtadt» Beim Autrut der Erk lärungskomponente 
werden die Syn tagmen dieses Modells mit den entsprechenden (ggt. be- 
reits tlektierten) Texten bzw. Var iab len inhal ten getüllt. Die syntak- 
tische Einteilung des Modells mu(l so tein sein, da(l der Text tür jedes 
Syntagma mit e^inem tür alle benutzten Sprachen identischen Suchbegritt 
adressiert werden kann, selbst wenn die so entstehende Einheit kein 
Syntagma im strengen Sinn mehr sein sollte. Auch 0-Syritagmen sind vor- 
zusehen (z.B. tür in bestimmten Sprachen wegtallende Artikel). 

Eine sprachabhäng ige Routine wählt dann die Syn tagmen in der tür die 
aktuelle Sprache richtigen Reihen toi ge aus und stellt den Satz zusam- 
men. Grundlage hi er tür ist ein eintaches sprachspez i t isches syntakti- 
sches Modell, das zu jedem vorkommenden Satztyp vorhanden sein mu(^. 



6. 1.5.3 Erklärung der Lie-ferantenbewertung 



Diese verbale Er k lärungskomponen te (absolut und relativ) , die als Pro- 
totyp aut EMS5S00 existiert, wurde zunächst nicht aut SINIX übernom- 
men , da noch weitere Un tersuchungen notwendig sind- Hier ist es einer- 
seits besonders schwierig, mit vertretbarem Autwand zu nicht banalen 
E.rgebnissen zu kommen, andererseits besteht von seiten der Einkäuter 
nur in Sonder täl len ein Bedart an maschineller verbaler Erklärung- 
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6. 1.5.4 Szenarienvergleich 



D i e sj i s 1 : e i i“i w 0 i t r e s sc h w i e r i g e s Feld, wo N u ± z b n u n d A u f w a fi d m i ± 0 i i"i - 
andei" streiten« Dei'zeit gibt es im EES rfur E?inen Szei'iar ie?nverg leich 
t ü r' d i e sp e z i eile S i t ua t*i oi"i d e v' L i e -f e i*' an t eri f r e i g ab 0 ; d i ese !•' w i r' d au t o- 
matisch bei der Neuer i’'echm..u"ig eines Szenarios nach der F-i-'eigabe bishEor' 
g 0 s p e r I“ 1 0 1 " H 0 r s t e^ 1 1 e i" a 1 s v 0 1 ' b a 1 0 E r k 1 ä r u n g a u s g 0 g e b e n . 

Die Fi' 0 i gE^bE?kDsteri je Her'steller ui“id Werk wurden vom Enünkäute?!- aut 
Antorderung des E'ES als Schätzung eing0g0be3n» HiE'?r wird gezeigt, ob 
u ri d i i"i w 0 1 c: h e? r' hl ö h e d i e F i-' e? i g a b e ei i"» e Ei n 0 u e n h! e r s i: e? 1 1 e r s 1 1 -' o t z F" r e i g a - 
bekosteri rentabesl ist, bzw. ws^lche Mehrkosten (tüi'' die betrachtete Pe- 
riode) zu erwarten und ggf- mit gewicht igesn Gründen zu rechtter t igen 
s i n d « 



6.2 Zielpreisermittlung 



Der aut EMS5S00 vorliegende Prototyp diess^is Bausteins ist auEisch 1 iE?ti- 
lich tür den operativen Einsatz unmittelbar vor Eintritt in die LiE^te- 
rari terivei'hand lurigeri gedacht« SE^in Ziel ist es, ausgehend voi"i dei'i lE?tz- 
t e i'i V o I' 1 i e g 0 n d e n P i' e i s 0 n u i"i t e i ' Be r' ü c k sich i: i g u ri g h 0 1' s t e? 1 1 e i' - u n d m a r- k t -■ 
bedingter Kriterien ein real ist isches preisliches Vc-jrhand lungsz iel zu 
ermi tteln« 

Die Auswahl urid Deutung der Eint lu( 3 tak toren ei'wies sich als heikles 
Prob lems 

Ab einer gewissen Anzahl und Komplexität der F-£\ktore 3 n ist ihre lauten- 
de Ertassung nicht mehr zu gewähr leisten ; gröi^ere Eintachheit bringt 
gröbere Ergebnisse« Die Wechsel wi r kungen der Faktoren un tereinander 
sind ott schwE^r zu tassen« Der absolute Wert eines Fa\ktors> ist ott nur 
i i"i V e 1' b i n d u r i g m i t a n d e? i ' b ri F' a F: t o i ' e ri (..i n d / o d e i ' v o r h e i ' i g e ri Z u s t ä n d e ri z u 
deuten» Dicjs ist nur ein Teil der Schwier igkei ten « 

Da«; d£?m Prototypen zugrundel legende eintache Autrechnungsmodel 1 tür 
F=’rE? isaut t r iebs- und -ver tal lstE?ndenzen erwies sich schnell als der 
Komplexität des Problems unangemessen « Weitere grundlegende Untersu- 
chungen hierzu sind notwendig und werden noch 1991 unternommen werden» 
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Angedacht :i.st ein komplexes regelbasier tes Modell mit Wahrschein 1 ich- 
k e i t s t a k t o r en , d a z u Heu r' i s t i k eri z u r' Au f 1 ö sui"i g vori ari d e r' s ri i c h t m i t 
vertretbarem Aufwand zu bewältigenden Problemstellungen. 



6.3 Strategiebaustein 



Dieser zukünftige Baustein soll sich strategischen Problemen widmen. 
Angedacht sind die Einbeziehung von 
. Por tf ol ioanalyse 
« E i i"! k a u f s m a 1 1 " i x 

« Sing le-Mul t ip 1 e-Sourc ing-Analyse 
. Top “down -Pr ob 1 ernste 1 lungen 

mit Simulat ionsmög 1 ichkei ten und Er k lärungskomponenten . 

Da es hier gro|3enteils um numerische Opt imierungsprob lerne auf hohem 
Niveau handelt, wird der Einsatz von Gperat ions-Research-Methoden ge- 
prüft werden müssen. Nichtnumer ische F'robleme können auf der symboli- 
schen Ebene der Eixper tensystemumgebung abgehandelt werden. 



6.4 EES-Einsatz 



Das EES ist bereits heute in folgenden Situationen einsetz bars 

Verband lungsvorberei tung 

Erarbeitung von Verhandlungsstrategien durch Analyse vor 1 legender An- 
gebote und durch Simulation der Auswirkungen möglicher Vorschläge und 
Gegenvorschläge, Zwischen- oder Teilergebnisse; Vorberei tung der Argu- 
mentation mithilfe der Er k lärungskomponente- 

Verhand lungstührung 

In Verhandlungspausen Eingabe von neuen Angeboten, Zwischen- und Teil- 
ergebnissen und schnelles Durch rechnen der finanziellen Konsequenzen , 
der Veränderungen in Herstel lerpaketen und der Folgen für die weitere 
Verband lungsf ührung mit demselben und anderen Lieferanten« 
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Verhandlungsauswertung 

Gegen uberste 1 luncj ei‘'hG-f-f ter und real is:i, er ter Abschlüsse dui'ch die ent 
s p r e c: h e n d e n S z e r i a r' i e n « 

Einkaufsstrategie-Findung. 

Du r c h die S i mu 1 a t i qi-i sm ö g 1 i c h k e i t en d es E"ES k ö i“i n ei"i k ammeri d e od er m ö g 1 i 
c he M a r k t e ri t w i c k' 1 u i"i g e i"i v o r- d e m E! i i"rt: i" e t e i"i d u r c h g e r e c hi i"i e t i.i n d ihre K o ri - 
Sequenzen für das Eiirikauf sgeschehen beurteilt werden» Der Einkäufer 
kann vom Reagieren zum Agiei'en übergehen, indem er kreativ mithilfe 
d es E E. S r e c h t z e i t i g a d ä u ä t e S t r a t e g i e !"i e n 1; wie !•:: e 1 1: « 



6.5 Technische Daten 



H a I' d w axr e ! kl X 3 0 0 o d e r M X 5 0 0 m i t G i' a p h i k t e r- m i ri a 1 978 0 8 
Softwaren SINIX mit COLLAGE 
P r og r amm i e r sp i' cic h e s LI SP-KCL 
Bet rieb Barts Menügef ühr t£^r Dialog 
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GENO-STAR 



EIN EXPERTENSYSTEM FÜR DIE KUNDENBERATUNG 
Dr. Klaus Kalefeld 
WGZ-BANK 

Westdeutsche Genossenschafts-Zentralbank eG 
Niederlassung Münster 



Die WGZ-BANK (Westdeutsche Genossenschafts-Zentralbank eG) ist das regionale Spit- 
zeninstitut für 553 Volksbanken, Raiffeisenbanken und Spar- und Darlehnskassen im 
Rheinland und in Westfalen. Das Bilanzvolumen dieser Bankengruppe beträgt rund 136 
Mrd. DM. Mit dem Expertensystem GENO-STAR (Genossenschaftlicher Staatshilfen-Ratge- 
ber) bietet die WGZ-BANK ihren Mitgliedsinstituten Beratungsunterstützung im Bereich 
öffentlicher Finanzierungshilfen an. 



Beratung als Service für den Kunden 

Aufgrund der dezentralen und sehr kundennahen Organisationsform zählen insbesondere 
mittel ständische Firmen sowie Privatkunden zum typischen Klientel der genossenschaft- 
lichen Bankengruppe. In ihren unternehmerischen Entscheidungen können sich diese 
Kunden in der Regel nicht auf größere Stabsabteilungen oder Fachleute für spezielle 
Themenkreise im eigenen Unternehmen stützen. Beratung als Service für diese Kunden- 
gruppe stellt somit einen wesentlichen Wettbewerbsfaktor für Banken dar. Dem haben 
die Genossenschaftsbanken schon in der Vergangenheit Rechnung getragen. 

Die ausgeprägte Mittelstandsorientierung begünstigt so die Wettbewerbsposition der 
Genossenschaftsbanken im Bereich der Vermittlung öffentlicher Finanzierungshilfen in 
Form von Zuschüssen oder zinsgünstigen Krediten, die sich durch lange Laufzeiten und 
Zinsbindungsfristen sowie Tilgungsfrei jahre und unproblematische Tilgungsmöglichkei- 
ten auszeichnen. Positiv beeinflußt wurde diese Situation zusätzlich durch die weit- 
gehende Ausrichtung der öffentlichen Finanzierungshilfen auf kleine und mittlere 
Unternehmen. So werden heute beinahe 4 von 10 Anträgen auf öffentliche Finanzierungs- 
hilfen bei Genossenschaftsbanken gestellt. 

Dementsprechend war und ist es eine wesentliche Aufgabe der WGZ-BANK, die Mitglieds- 
banken beim Ausbau ihrer Marktposition zu unterstützen. So bietet die WGZ-BANK den 
Volksbanken und Raiffeisenbanken seit Jahren kompetente Informationen und aktive 
Beratung an, damit sie ihren Kunden die Vorteile öffentlicher Finanzierungshilfen 
erschließen können. Im Interesse der Kunden waren die Genossenschaftsbanken immer 
bemüht, diese Finanzierungshilfen nicht nur isoliert anzubieten, sondern in bestmög- 
licher Kombination bereitzustellen. 
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Allerdings muß schon bei einer einfachen Investitionsmaßnahme eine Vielzahl von Kre- 
dit- oder Zuschußprogrammen auf EG-, Bundes- und Landesebene auf ihre Einsatzmög- 
lichkeit geprüft werden. Heute kann nur noch ein besonders geschulter Experte mit 
hohem Kosten- und intensivem Zeitaufwand die optimale Lösung finden, weil die zahl- 
reichen Variations- und Kombinationsmöglichkeiten sich potenzieren. 

Erschwerend wirkt, daß eine allein auf Richtlinientexte gestützte Beratung in der 
Regel nicht zum optimalen Ergebnis führt, da neben den veröffentlichten Texten die 
jeweilige "Bewilligungspraxis" der Refinanzierungsstellen, die als geldgebende Insti- 
tutionen die subventionierten Mittel bereitstellen, eine beinahe gleichgewichtige 
Bedeutung hat. Da die WGZ-BANK Jahr für Jahr tausende von Anträgen - allein im letz- 
ten Jahr 13 000 Stück - für öffentliche Finanzierungshilfen bearbeitet, wurde Exper- 
tenwissen mit einschlägigen Praxiserfahrungen gewonnen, wie es dezentral kaum er- 
reichbar wäre. Die Qualität der Beratung und Betreuung der Kunden vor Ort durch die 
Volksbanken und Raiffeisenbanken hängt somit entscheidend davon ab, wie gut es einer 
Zentralbank gelingt, ihr spezielles Know-how den örtlichen Banken zur Verfügung zu 
stellen. 



Informationsflut als Problem 



Die Informationsflut, die auch zukünftig über die Privat- und Firmenkunden ebenso 
wie über die Banken hereinbrechen wird, ist voraussehbar. Allein die Schaffung des 
gemeinsamen Europäischen Marktes und die Wiedervereinigung mit der DDR führen dazu, 
daß sich jedes Unternehmen mit den neuen Möglichkeiten, den Märkten, den Produkten 
und den Wettbewerbern national und international befassen muß, um die eigene Fort- 
entwicklung sicherzustellen. Während sich größere Unternehmen durch Nutzung eigener 
Stabsabteilungen die notwendige Übersicht verschaffen können, haben insbesondere 
mittel ständische Unternehmen in der Regel diese Möglichkeit nicht. Die Fülle der 
mittelstandsorientierten Berater in Kammern und Verbänden, bei Banken, Steuerbera- 
tern und Rechtsanwälten legen deutliches Zeugnis dafür ab, wieviele Informationen es 
für mittel ständische Unternehmen zu verarbeiten gilt. 

Dieses Informationsproblem gleicht im Grundsatz dem der Firmenkundenbetreuer einer 
Bank. Auch sie müssen über alle Daten verfügen können, die im Rahmen einer Kundenbe- 
treuung von Bedeutung sein könnten, da sie der primäre Ansprechpartner der Kunden 
sind. Die Abkehr von der Sparten- zur Kundenorientierung bei den Banken zeigt deut- 
lich, wie weit man dem Kunden in seinem Wunsch nach einem Ansprechpartner gefolgt 
ist. Die Fülle der Informationen, die der Bankmitarbeiter für seinen Kunden aufzube- 
reiten hat, erreicht allerdings zunehmend Dimensionen, die mit traditionellen Mit- 
teln nicht mehr beherrschbar sind. Allein im Bereich der öffentlichen Finanzierungs- 
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hilfen, die von der EG, dem Bund und den Ländern bereitgestell t werden, ergeben sich 
nahezu täglich Änderungen, die ggf. von den Firmenkundenbetreuern in ihren Beratun- 
gen berücksichtigt werden müssen. Der Zeitaufwand für die Informationsaufnahme und 
die permanente Aktualisierung des Wissens setzen dem menschlichen Experten Grenzen. 
So kann der Kundenbetreuer in der Regel nur ein qualifizierter Generalist mit par- 
tiellem Spezialisierungsgrad sein, der Probleme einzuordnen weiß und Lösungswege 
durch Einschaltung von Fachexperten eröffnen kann. 

Die in eine Problemlösung einzubindenden Spezialisten wiederum bilden sich bei der 
heutigen Entwicklung des Angebots von Finanzdienstleistungen zu immer stärkeren 
Fachexperten heraus, die allein noch in der Lage sind, ein sparten- oder produktbe- 
zogenes Optimum für den Kunden zu finden. Der Erfolg der Banken hängt somit davon 
ab, ob es gelingt, das vielfältige Know-how in einer Form zur Verfügung zu stellen, 
die es einem Kundenbetreuer vor Ort ermöglicht, eine kompetente, komplexe Beratung 
des Kunden durchzuführen. Nur das Zurverfügungstellen von Daten reicht nicht aus, es 
müssen zielgerichtete und damit für den Einzelfall relevante Informationen sein. So 
war es folgerichtig, daß die WGZ-BANK durch Einsatz eines neuen EDV-Verfahrens die- 
ses Problem im Bereich der Zuschüsse und Programmkredite gelöst hat und damit die 
Beratungskompetenz der Mitgliedsbanken weiter erhöhen konnte. 



Verbesserung der Beratungskompetenz 

Für die Entwicklung eines EDV-Systems sprach die Tatsache, daß im Geschäftsgebiet 
der WGZ-BANK durch die Verbindung zu den Rechenzentren rund 12 000 Terminals bei den 
Mitgliedsbanken zur Übertragung und dezentralen Abfrage von Expertenwissen nutzbar 
gemacht werden konnten. Es galt somit, Expertenwissen der Zentralbank so abrufbar in 
die Onl ine-Infrastruktur einzuspeisen, daß die Mitgliedsbanken vor Ort im Bereich 
der öffentlichen Finanzierungshilfen die Informationen erhalten, die sie für den 
konkreten Fall benötigen. 

So kann heute mittels des Expertensystems GENO-STAR das Know-how der Zentralbank 
schnell, lückenlos und präzise den Mitgliedsbanken über die bestehende Onl ine-Infra- 
struktur zur Verfügung gestellt werden. 

GENO-STAR ist ein menügeführtes, intelligentes Dialogverfahren, das selbst ungeübten 
und unerfahrenen Mitarbeitern einer Ortsbank eine kompetente Kundenberatung ermög- 
licht. Die Inhalte des Expertensystems werden von den Fachspezialisten der Zentral- 
bank gepflegt und weiterentwickelt, so daß zentral vorhandenes Know-how dezentral 
- selbst in der kleinsten Zweigstelle einer Genossenschaftsbank - nutzbar wird. 
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GENO-STAR ist in der Lage 

die in Frage kommenden öffentlichen Finanzierungsmöglichkeiten zu selektieren, 
diese richtliniengemäß optimal zu kombinieren, 
die Bewilligungspraxis zu berücksichtigen, 

einen konkreten Finanzierungs- und Kapitaldienstplan zu erstellen, 
eigene Mittel der Hausbank zur Deckung des Restkreditbedarfes zu berücksich- 
tigen, 

dem Kunden wie dem Berater Hinweise zur Antragstellung zu geben. 

Der Dialog mit dem Expertensystem vermittelt somit dem Kundenbetreuer Sicherheit und 
garantiert eine effiziente und qualifizierte Beratung der Kunden, die ein Experte 
nur bei großem Fachwissen und hoher Konzentration ohne EDV-Unterstützung erreichen 
könnte. Selbst komplexe Kombinationen mehrerer Finanzierungsprogramme der verschie- 
densten Förderbereiche von EG, Bund und Land werden investitionsbezogen, schnell und 
fehlerfrei ermittelt. So wird sichergestellt, daß kein Aspekt übersehen und aus tau- 
senden von Möglichkeiten tatsächlich der optimale Finanzierungsplan ermittelt wird. 



Flexibilität des Expertensystems 

Damit das Expertensystem eine effektive Beratungsunterstützung sicherstellen kann, 
arbeiten mehrere Komponenten zusammen, die sich dem Anwender durch eine benutzer- 
freundliche Dialogkomponente präsentieren. Durch die komfortable Menüführung wird 
der Firmenkundenbetreuer - gemeinsam mit dem Kunden - auf dem kürzesten Weg zum Er- 
gebnis geführt, wobei das Expertensystem, quasi wie ein menschlicher Experte, nur 
unbedingt notwendige Fragen stellt. Während des Dialogs können Angaben geändert oder 
präzisiert werden. Sobald Neueingaben Auswirkungen auf die Nutzbarkeit von Förder- 
programmen oder die Förderhöhe haben, werden diese Änderungen sofort berücksichtigt. 
GENO-STAR optimiert neu und stellt aufgrund der gewandelten Ausgangssituation even- 
tuell noch notwendige Fragen. Somit läßt sich schon im Vorfeld einer Investitons- 
planung simulieren, wie sich Veränderungen in den Kostenblöcken oder die Wahl ver- 
schiedener Standorte für das Unternehmen auf die Finanzierungsmöglichkeiten auswir- 
ken. 

Der Vorgehensweise von GENO-STAR liegt die Strategie zugrunde, dem Investor die 
zinsgünstigste Finanzierung im Mix der öffentlichen Kredit- und Zuschußprogramme 
zusammenzustellen. Dementsprechend erstellt das Expertensystem zunächst eine Rang- 
folge der konkret ausgewählten Programme. Bei der sofortigen Ermittlung des Finan- 
zierungsplanes werden dann nur die für den Kunden attraktivsten Programme jeweils 
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richtliniengemäß maximal ausgeschöpft. Sofern sie nicht alle zur Finanzierung benö- 
tigt werden, streicht das Expertensystem automatisch die weniger zinsgünstigen Pro- 
gramme. Ein notwendiger Restkreditbedarf kann durch die Hausbank abgedeckt und nach 
Eingabe der Konditionen mit in den Finanzierungs- und Kaptialdienstplan eingebettet 
werden. Finanzierungs- wie Kapitaldienstplan lassen sich ausdrucken und können dem 
Kunden für weitere Planungsarbeiten unmittelbar ausgehändigt werden. 

Diese Leistungsfähigkeit des Systems GENO-STAR wird durch die Nutzung von ESE (Ex- 
pert System Environment) der IBM ermöglicht, dessen derzeit größter Nutzer im Fi- 
nanzdienstleistungsbereich die WGZ-BANK ist. 

Die Experten der WGZ-BANK geben das Wissen über öffentliche Finanzierungshilfen so- 
wie die Bewilligungspraxis als Fakten und Regeln in das System ein. Hierdurch ent- 
steht eine komplexe Wissensbasis, die ständig durch die WGZ-BANK aktualisiert wird. 
Tagaktuell werden zum Beispiel Konditionsänderungen, Veröffentlichungen neuer Richt- 
linien oder Änderungen in der Bewilligungspraxis in das Beratungssystem aufgenommen. 
Bei einer Onl ine-Beratung durch den Firmenkundenbetreuer einer örtlichen Genossen- 
schaftsbank leitet die Deduktionskomponente aus dem gespeicherten Wissen (Fakten und 
Regeln) die jeweils für den konkreten Einzelfall relevanten - und nur die - Fragen 
ab. Das System ist so ausgelegt, daß sowohl der erfahrene wie auch der unerfahrene 
Firmenkundenbetreuer einen Dialog auf jeweils dem Niveau führen kann, das genau sei- 
nem Wissensstand entspricht. Während der erfahrene Berater aufgrund seiner Hinter- 
grundkenntnisse zügig die ihm gestellten Fragen abhandeln kann (er versteht, wonach 
er gefragt Wird), kann der unerfahrene Mitarbeiter sich jeden Fragetext und die Ant- 
wortmöglichkeiten ausführlich erläutern lassen, damit er auch ohne Vorkenntnisse zur 
einem qualifizierten Beratungsergebnis kommt. 

In den vorgenannten Aspekten unterscheidet sich GENO-STAR von anderen Expertensyste- 
men. Zum einen stellt sich GENO-STAR mittels einer weit ausgearbeiteten Erklärungs- 
komponente auf den jeweiligen Qualifikationsstand des Nutzers ein, und zum anderen 
beinhaltet GENO-STAR keine im Zeitablauf konstante, sondern eine äußerst flexible 
Wissensbasis, die ständig neuen Informationen angepaßt werden muß. Durch diese täg- 
liche Aktualisierung der Wissensbasis wird eine bisher nicht vorstellbare Geschwin- 
digkeit des Wissenstransfers von der Zentralbank zu den örtlichen Genossenschafts- 
banken erreicht. Die Sicherstellung einer qualifizierten Beratung wird somit selbst 
in einer extrem dezentralen Organisationsstruktur mühelos möglich. 
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GENO-STAR als Gesamtsystem 

Neben dem bisher dargestellten Beratungssystem besteht GENO-STAR noch aus einem In- 
formations- und Kommunikationssystem. Werden beispielsweise konkrete Informationen 
über ein bestimmtes Finanzierungsprogramm oder aktuelle Konditionen gesucht, so 
steht das Onl ine-Informationssystem von GENO-STAR zur Verfügung. Es informiert um- 
fassend und aktuell und ersetzt einen aufwendigen Rundschreibendienst, der in der 
Vergangenheit zur Aktualisierung einer Loseblattsammlung über Zuschüsse und Pro- 
grammkredite aufrechterhalten werden mußte. Im Informationsteil von GENO-STAR werden 
die Finanzierungshilfen für die Bereiche 

Gewerbliche Wirtschaft 

Landwirtschaft 

Wohnungsbau 

in Form von Kurzbeschreibungen, gültigen Richtlinientexten sowie durch Hinweise zur 
Bewilligungspraxis ausführlich dargestellt. Zudem lassen sich tagaktuelle Nachrich- 
ten, Konditionen und Fördergebietslisten abrufen. 



Experten-System GENO-STÄR 




Das Kommunikationssystem von GENO-STAR wird es zukünftig ermöglichen, nicht nur den 
Finanzierungs- und Kapitaldienstplan zu erstellen, sondern bereits online die An- 
träge für die konkreten Förderprogramme aufzubereiten. Ziel der WGZ-BANK ist es, zu- 
künftig die Anträge selbst auch nur noch auf elektronischem Wege zwischen den Volks- 
banken und Raiffeisenbanken und der Zentralbank auszutauschen. Letztendlich könnte 
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dann der gesamte Schriftverkehr in Form von Zusagen, Abrufen, Nachfragen etc. zwi- 
schen der Zentralbank und den Refinanzierungsstellen und zwischen der Zentralbank 
und den Genossenschaftsbanken allein auf elektronischem Wege online erfolgen. Damit 
ließe sich der Aufwand für die Beantragung weiter deutlich reduzieren. Die Basis für 
die Antragstellung wird aber immer der Finanzierungsplan sein, den GENO-STAR bereits 
jetzt für den Kunden erstellt. 



Organisatorisch-technische Integration 

Um die Vorteile eines Systems wie GENO-STAR effizient nutzen zu können, wird ein 
hohes Niveau der gesamten EDV-Anwendungsarchitektur einer Organisation vorausge- 
setzt. Denn erst die Möglichkeit, zentral gesammeltes Expertenwissen breit gestreut 
zur Verfügung zu stellen und dabei Onl ine-Infrastrukturen ebenso wie gemeinsam defi- 
nierte Standards im Bereich der Software und Hardware nutzen zu können, ermöglicht 
es, derartige elektronische Verfahren kosteneffizient bei der Beratung der Kunden 
der Genossenschaftsbanken einzusetzen. Im Verbund der WGZ-BANK mit den Genossen- 
schaftsbanken und den Rechenzentren bestehen dafür optimale Voraussetzungen. 

Neben der technischen Integration von GENO-STAR hatte die organisatorische Integra- 
tion eine hohe Bedeutung. GENO-STAR wird nämlich schwerpunktmäßig von der Fachabtei- 
lung betreut. Der größte Nachteil bei der Entwicklung von EDV-Systemen bestand in 
der Vergangenheit darin, dem technisch orientierten EDV-Fachmann die Wünsche der 
Fachabteilungsexperten unmißverständlich zu verdeutlichen. Die kontinuierlichen Ver- 
änderungen bei den öffentlichen Finanzierungshilfen zwingen jedoch zu jeweils mehr 
oder minder tiefgreifenden Veränderungen des Regelwerks. Die permanente Einschaltung 
einer EDV-Abteilung wäre bei den hohen Anforderungen an die Aktualität des Systems 
wenig praktikabel. 

Hier zeigen sich die deutlichen Vorteile von ESE, die es möglich machen, das Exper- 
tensystem zukünftig allein durch die Fachabteilung zu aktualisieren. Die positiven 
Erfahrungen des Einsatzes von GENO-STAR belegen, wie erfolgversprechend dieser Weg 
ist. Als wohl klassisches Beispiel für die Flexibilität und die Schnelligkeit des 
Systems wird man die Integration der Finanzierungshilfen für die DDR nennen können. 
Gleich nach Öffnung der Förderprogramme aus dem ERP-Sondervermögen für die DDR konn- 
ten diese in GENO-STAR auf genommen und in das Beratungssystem eingefügt werden. So- 
mit konnte sich ein westdeutscher Unternehmer bereits im März dieses Jahres durch 
GENO-STAR errechnen lassen, welche Finanzierungshilfen er erhält, wenn er in der DDR 
investiert. Dieses Beispiel der Aufnahme eines neuen Staates, der als Investitions- 
ort in Frage kommt, belegt, wie flexibel GENO-STAR auf Änderungen in der Wissensba- 
sis reagiert. 
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Perspektiven für Expertensysteme 

Der flächendeckende Einsatz von GENO-STAR im Geschäftsgebiet der WGZ-BANK (Rheinland 
und Westfalen) bei allen Volksbanken und Raiffeisenbanken beweist die Notwendigkeit 
und Akzeptanz dieses Systems. Der Ausbau von GENO-STAR zu einem Beratungssystem, das 
auch über das Geschäftsgebiet der WGZ-BANK hinaus beraten kann, wurde im letzten 
Quartal 1989 in Angriff genommen. Inzwischen sind auch die norddeutschen Förderpro- 
gramme enthalten, und weitere Bundesländer werden folgen. Neben dem bundesweiten 
Ausbau von GENO-STAR wird die Weiterentwicklung des bereits erwähnten Kommunika- 
tionssystems die Zukunft prägen. 

Für die WGZ-BANK und die Volksbanken und Raiffeisenbanken wurde mit GENO-STAR der 
Einstieg in die Expertensystemtechnologie erfolgreich in Angriff genommen. Gerade im 
Bereich der Banken bieten sich viele Verwendungsmöglichkeiten für Expertensysteme 
an, die quasi eine Brücke schlagen zwischen den Spezialisten der Fachabteilungen und 
den kundenorientierten Betreuern, die eher als qualifizierte Generalisten zu ver- 
stehen sind. 




Erfahrungen bei der Entwicklung und beim Einsatz von Expertensystemen in der 

WestLB 
J. Minnemann 
Westdeutsche Landesbank 
Düsseldorf 



Initiative 

In der Westdeutschen Landesbank gibt es seit vielen Jahren eine Abteilimg, die für 
Operations Research-Anwendungen zuständig ist. Naturgemäß werden von dort 
auch die verschiedensten Entwicklungen zur Unterstützung der Entscheidungs- 
findung beobachtet, und nach Möglichkeit wird deren Umsetzung initiiert bzw. 
unterstützt. Es war daher naheliegend, daß diese Stelle den Auftrag erhielt, den 
Expertensystemansatz zu eruieren. Erfreulich und von großer Bedeutung war, daß 
die Initiative hierzu im Jahr 1987 von dem für Datenverarbeitung zuständigen 
Vorstandsmitglied ausging. 

Als nicht unbedingt positive Voraussetzung für diesen Auftrag mußte der 
Tatbestand angesehen werden, daß das Thema Expertensysteme in der Fachpresse 
bereits ein sehr großes Echo gefunden hatte. Ganz im Gegensatz zu anderen 
Möglichkeiten der DV-Unterstützung in der Vergangenheit, waren die Erwar- 
tungen und Versprechungen sehr hochgestellt. Aussagen über angeblich realisierte 
Systeme ließen erhebliche Vorteile erwarten. Stellenweise wurde die Notwendigkeit 
der Entwicklung von Expertensystemen als absolut zwingend herausgestellt. 
Expertensysteme wurden dabei und werden heute noch als "Strategische Waffe" 
bezeichnet. Der hausinterne Auftrag zum Thema Expertensysteme sollte aufzeigen, 
was der Ansatz beinhaltet und ob eine intensive Verfolgung für die WestLB 
sinnvoll sein kann. 
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Strategie 

Ausgangspunkt für die weiteren Überlegungen war die Feststellung, daß Know how 
auf dem Gebiet der Expertensysteme im eigenen Hause nicht existierte. Eine 
Zusammenarbeit mit Externen lag daher nahe. In Betracht kamen Softwarehäuser, 
Hard- und Software-Hersteller oder auch Hochschulinstitute. Gegen die Ein- 
schaltung von Softwarehäusern sprach, daß noch kein konkretes Anwendungs- 
projekt festgelegt war und daß relativ hohe Kosten entstanden wären, um einen 
ersten Überblick über die Anwendungsmöglichkeiten zu gewinnen. 

Großrechnerwerkzeuge waren zu diesem Zeitpunkt praktisch nicht verfügbar bzw. 
ungeeignet. Die Entscheidung zugunsten einer Zusammenarbeit mit mehreren 
Hochschulinstituten ließ erheblichen Freiraum. Die Möglichkeit des Scheiterns 
mußte von vornherein deutlich ausgesprochen werden. Die Realisationsform der 
Zusammenarbeit bestand in der Förderung von Studien- und Diplomarbeiten. 
Dabei sollten "vorzeigbare" Systeme, Pilotsysteme, mit einem geeigneten Werkzeug 
entwickelt werden. 

Um eine geeignete Hardware- /Software-Kombination für die Entwicklung von 
Expertensystemen auszuwählen, wurden zunächst die bekannten und zugänglichen 
Möglichkeiten grob analysiert. Shells, die nur auf dem Großrechner verfügbar 
waren schieden aus, da einerseits die Kosten zu hoch waren und andererseits die 
Zusammenarbeit beeinträchtigt gewesen wäre, da sich die gleiche DV-Umgebung 
wie in der WestLB an keiner Hochschule wiederfindet. Es mußten somit 
PC-Systeme sein. Die Entscheidung fiel schließlich zugunsten der Experten- 
system-Shell Nexpert Object; als Hardware wurde der Apple Macintosh festgelegt, 
um die grafische Oberfläche zu nutzen. Das Werkzeug und dessen Einsatz- 
möglichkeiten zeigten ein gutes Preis-Leistungsverhältnis. Weiterhin bestand 
bereits die Zusage des Herstellers, Neuron Data in Kalifornien, eine 
MS-DOS-Version in naher Zukunft auszuliefern. 
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Themenauswahl 

Die Kriterien zur Auswahl eines geeigneten Anwendungsgebietes für ein 
Expertensystem sind aus der Literatur hinreichend bekannt. Neben diesen Kriterien 
kam im konkreten Fall unseres Hauses zusätzlich zum Tragen, daß Studenten bei 
einer derartigen Aufgabe eingesetzt werden sollten. Dadurch schlossen sich 
bestimmte Gebiete von vornherein aus. Es war weiterhin eine frühzeitige 
Erkenntnis, das Vorurteile und Probleme im Zusammenhang mit dem Thema 
Expertensysteme gerade aus dem Bereich der EDV kamen bzw. kommen werden. 
Daher wurde Wert darauf gelegt, daß auch Anwendungsgebiete aus diesem Bereich 
bestimmt wurden. Es ergab sich im Laufe der Zeit schließlich folgende Festlegung 
von Arbeitsgebieten: 

- Anlageberatung 

- Aufwandsschätzung für Software-Entwicklungsprojekte 

- Kreditgewährungsanalyse (Bonitätsprüfung) 

- Leasingbeurteilung 

- Reisekostenbearbeitung 

- Unterstützung des Operating im Rechenzentrum 

Drei Aufgabengebiete erklären sich selbst; die anderen sollen kurz beschrieben 
werden. Leasingbeurteilung bedeutet die Auswahl von Finanzrechnungs- 
möglichkeiten imter besonderer Berücksichtigung des Leasings. Die Planung imd 
Abrechnung von Reisen kann dann zu einem Problem werden, wenn es sich um 
größere Auslandsreisen handelt. Je nach Reiseland sind völlig unterschiedliche 
Bestinunungen zu beachten. Beispielsweise muß in einem Land die Landung bis zu 
einer bestimmten Uhrzeit erfolgt sein, damit der Spesensatz dieses Landes an 
diesem Tag zum Tragen kommt. Bei der Unterstützung des Operating im 
Rechenzentrum geht es insbesondere um die Hilfe beim sog. IPL (Initial Programm 
Load), dem Einschalten oder Hochfahren der Rechner, das ungefähr 20 bis 30 
Minuten dauert. Von besonderer Bedeutung ist der Störfall, d.h. die Unterbrechung 
des Normalbetriebs. Hier ist vom Operating in kürzester Zeit eine Ursachenanalyse 
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durchzuführen und der Normalbetrieb wieder aufzunehmen. Da im Onlinebetrieb 
des Rechenzentrums der WestLB ca. 10.000 Terminals bedient werden müssen, ist 
leicht zu erkennen, welche Kostendimension bei Ausfall des Online-Systems 
angesprochen ist, abgesehen von dem durch Nichtbereithaltung von Dienst- 
leistungen entstandenen immateriellen Schaden. 



Pro j ektinitiierung 

Themenauswahl und Projektinitiierung gehen eng ineinander über. Die zahlrei- 
chen Gespräche mit Fachabteilungen haben zunächst eine Reihe von elementaren 
Problemen zutage gefördert. Die erste Frage hieß: Wie begeistert man jemanden für 
die Mitarbeit bei der Entwicklung eines Expertensystems, der nicht weiß, was das 
überhaupt ist? Die zweite Frage lautete: Wer ist bereit, auf diesem neuen Gebiet zu 
investieren und das Risiko des Scheiterns eines Pilotprojektes zu tragen. Hinzu 
kam: Wie hoch ist das Risiko und welche Konsequenzen hat ein Fehlschlag? 

Die Aufklärungsarbeit über das, was Expertensysteme leisten sollen und können, 
erwies sich zum Teil als sehr schwierig. Zu den Kernschwierigkeiten zählte die 
Beantwortung der Frage: Wie unterscheidet sich ein Expertensystem von "klassi- 
schen EDV-Systemen? Zu dieser Frage gibt es auch heute noch relativ wenig kon- 
krete und zugleich leicht verständliche Aussagen. Leichte Verständlichkeit ist wich- 
tig, weil diese Frage nicht nur mit EDV-Experten, sondern gerade mit Mitarbeitern 
aus den Fachbereichen, die nicht sehr intensiv mit EDV-Fragen beschäftigt sind, er- 
örtert werden muß. 

Zur Vereinfachung des Einstiegs in die Projekte mußten bereits einige Vorarbeiten 
erbracht werden. So wurden Demonstrationssysteme zum Zwecke des Vorzeigens 
auf den Rechner gebracht. In einigen Fällen galt: Nur wenn es gelang, andeu- 
tungsweise zu veranschaulichen, was ein System beinhalten bzw. wie es funkti- 
onieren würde, konnte man relativ leicht den Zugang zu den gewünschten Exper- 
ten erhalten. Bei diesen Demonstrationssystemen wurde unterschieden zwischen 
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Systemen aus dem Bereich der jeweiligen Fachexperten einerseits und 
bereichsfremden Systemen andererseits. Ein guter Ansatzpunkt für eine weitere 
Zusammenarbeit war dann erkennbar, wenn bei der Vorführung eines Demon- 
strationssystems aus dem eigenen Bereich als Reaktion ein klares "so nicht, 
sondern" kam. Mit dieser Antwort wurde zu erkennen gegeben, daß man sich 
grundsätzlich den Einsatz eines Systems vorstellen kann, daß es aber anders, als 
bisher geschehen, realisiert werden muß. Die Entscheidung für die Demonstration 
eines Systems aus einem fremden Bereich bewährte sich ebenfalls in einigen Fällen. 
Die günstigste Reaktion bestand darin, daß die Frage gestellt wurde, ob etwas 
derartiges auch für den Bereich des jeweiligen Experten gemacht werden könne. 

Ein weiterer Problempunkt im Rahmen der Projektinitiierung war die Heraus- 
hebung der Unterschiede zur üblichen Zusammenarbeit mit der EDV. EDV-Abtei- 
lungen müssen sich mitunter mit einem mehr oder weniger starken Negativimage 
abfinden. Hinzu kommt die von Fachabteilungen manchmal als starr empfundene 
Vorgehens weise bei der Projektrealisierung, angefangen von einem Antrag über 
eine Vorstudie und den Ressourcenverteilungsprozeß (ggfs, über einen Priori- 
tätenkreis) bis zur Projektrealisierung. Im vorliegenden Fall der Durchführung von 
Pilotstudien zur Entwicklung von Expertensystemen, mußte dagegen kein 
Projektvertrag unterschrieben werden. Es war keine Kapazität zu beantragen und 
ggfs, gegen andere Projekte durchzusetzen. Lediglich die Fachabteilung selbst mußte 
Personalkapazität in Form der Expertenbeteiligung zur Verfügung stellen. Das 
bedeutete eine Vereinfachung. Die 6 ausgewählten Arbeitsbereiche bedeuteten 
dagegen aber nicht 6 vorbereitende Gespräche; es war eine nicht erwartete Vielzahl 
von Besprechungen erforderlich, um die gewünschte Unterstützung und die 
gesuchten Experten zu finden. 



Information 

Bereits zu einem sehr frühen 2^itpunkt hatte sich die Frage nach einer geeigneten 
Information über Ziel und Inhalt von Expertensystemen als besonders wichtig er- 
wiesen. Daher wurde bereits im Juni 1988 eine erste Informationsschrift zum The- 
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ma "Expertensysteme in der Praxis" zusammengestellt . Es wurden Expertensystem- 
Anwendungen aus verschiedenen d.h. auch industriellen Anwendungsbereichen 
aufgeführt, wobei jedoch deutlich die Vermutung geäußert werden mußte, daß ein 
Praxiseinsatz nicht immer sichergestellt ist. Weiterhin enthielt diese Schrift die 
damals jüngsten Informationen des Pressereferats aus dem Bundesministerium für 
Forschung und Technologie zum Thema Forschungszentrum für Künstliche 
Intelligenz mit den ergänzenden Definitionen. 

Im Januar 1989 konnte eine erste hausinterne Broschüre zum Thema "Experten- 
systeme in der WestLB" fertiggestellt werden. Hierin waren alle Anwendungsgebie- 
te und Prototypen angeführt, an denen z.Z. gearbeitet wurde. 

Parallel zu den schriftlichen Informationen wurden regelmäßig Präsentationen vor 
kleinem oder größerem Zuhörerkreis durchgeführt. Zum einen handelte es sich um 
die bereits erwähnten Demonstrationsbeispiele zur Erläuterung des grundsätzlichen 
Anliegens und Vorgehens von Expertensystemen, zum anderen wurden die bereits 
vorliegenden Pilotsysteme vor größerem Zuhörerkreis im Hause vorgestellt. Dabei 
waren jeweils die entsprechenden Experten aus den Fachabteilungen anwesend, die 
eigentlichen Entwickler und zahlreiche z.T. bis zu 100 Interessenten aus 
verschiedenen Fachbereichen. Der Ablauf dieser Veranstaltung gestaltete sich in der 
Regel immer in der gleichen Form: Nach einer Kurzbeschreibung des Ansatzes von 
Expertensystemen wurde die praktische Vorgehensweise der WestLB in Form der 
Zusammenarbeit mit Hochschulinstituten erläutert, und es wurden die verschie- 
denen Ansätze kurz vorgestellt. Anschließend wurden die Pilotsysteme von den 
Experten aus der jeweiligen Fachabteilung vorgeführt. 

Die Reaktion auf diese Veranstaltungen und die gewählte Vorgehens weise war 
durchweg positiv. Lediglich in einem einzigen Fall ergab sich eine überraschende 
Reaktion: Ein Mitarbeiter aus einer Fachabteilung hielt das System für nicht so gut 
wie sich selbst. Derartige Mißverständnisse konnten leicht beseitigt werden. 
Wesentlich problematischer waren Äußerungen wie: "Das haben wir doch schon 
vor 5 Jahren gemacht", oder: "Jetzt werden alte Systeme unter neuer Überschrift 
verkauft". 
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Derartige Reaktionen waren verständlich, insbesondere wenn man berücksichtigt, 
daß die Fachpresse in der Zwischenzeit das Thema mit verschiedenen 
Schattierungen beleuchtete. Gefördert wurden diese Ansichten z.T. auch durch Soft- 
warehäuser, die in ihren Prospekten 'T5 Jahre Erfahrung auf dem Gebiet der 
Expertensysteme" anboten. Bei allen Präsentationen trat jedoch immer wieder die 
inzwischen klassische Fragestellung auf: Was ist ein Expertensystem imd was ist der 
Unterschied zwischen Expertensystemen und anderen EDV-Systemen? 

Die Frage nach dem Ziel und Inhalt von Expertensystemen konnte inzwischen 
durch schriftliches "neutrales" Material andeutungsweise beantwortet werden. 
Zusätzlich wurde ein computer-gestütztes Lernsystem zur Einführung in Exper- 
tensysteme entwickelt und zur Benutzung zur Verfügung gestellt. Die zweite Frage 
nach der Abgrenzimg von Expertensystemen und klassischen EDV-Systemen wurde 
versuchsweise durch folgende Folie erläutert: 

Was hebt Expertensysteme von 

konventionellen Systemen ab? 



Verarbeitung v agen Wissens 

• Aas der Eingabe von xmsicherexn und ungenauem \Mssen 
können Schlüsse gezogen und Probleme gelöst werden. 

- Der Benutzer kann Eingaben, '»'ie zJB. ’lch weiß nicht genau”, 
machen vuid ^xird dann vom S>*stem zur Problem* 
lösung geführt 




Leichte Än^erbarheit 

Es kann problemlos neues Wissen in die ^Issen^asis 
hinzugefügt und nicht mehr aktuelles Wissen heraus* 
genommen werden. 



V 



Erklärungsfähigkeit 
Esqpertens^’sieme können dem Benutzer Aufschluß über 
den Problemlösungsu’eg geben. 

Benutzerfragen, zJ3. 'Warum i^nirde gerade diese Lösung 
ausgewählt?' und 'Wie kam das Sj’stem zu dieser Lösung?' 
können beantu’oriet werden. 




211 



Neben der hausinternen Information wurde frühzeitig Wert darauf gelegt, daß 
durch externe Information bei Workshops, Seminaren oder Kongressen ein Gedan- 
kenaustausch zu den einzelnen Anwendungen möglich war. 



Projektabwicklung 

Inzwischen war im Hause der WestLB mit dem Aufbau eines kleinen Teams für 
Expertensysteme begonnen worden. Von den o.g. 6 Projekten konnten daher 2 aus- 
schließlich in eigener Regie abgewickelt werden. Die Pilotsysteme zu den anderen 
Gebieten sollten grundsätzlich von Studenten erstellt werden, wie dies mit ersten 
Demonstrationsbeispielen für die genannten Informationsveranstaltungen schon 
der Fall war. Die Vorstellung, daß Studenten bei dieser Arbeit lediglich begleitet 
werden müssen, erwies sich als falsch. Es zeigte sich vielmehr sehr früh, daß die 
Studentenprojekte mit relativ hohem Aufwand verbunden waren. Problematisch 
war bereits die Auswahl der Studenten für eine bestimmte Aufgabenstellung: Es 
mußte von vornherein ein gemeinsames Interesse von Experten und Studenten 
sichergestellt sein. Wesentlich war weiterhin die Befähigung der Studenten, ein 
Arbeitsgebiet auch dann weiterzuverfolgen, wenn es komplex war und noch nicht 
durch eigene Erfahrung abgedeckt werden konnte. 

Die Erfassung des Expertenwissens war in der Regel nicht schwierig. Probleme er- 
gaben sich vielmehr daraus, daß in mehreren Fällen erst die Frage eruiert werden 
mußte, wer Experte ist bzw. ob es "den" Experten überhaupt gibt. Alle angefangenen 
Projekte haben zumindest zu einem vorzeigbaren Pilotsystem geführt; in einigen 
Fällen sind sogar bemerkenswerte Ergebnisse entstanden, die ausgebaut werden 
konnten und z.T. noch ausgebaut werden. Alle Ergebnisse wurden an verschiedener 
Stelle präsentiert. Mehrfach war die Ergebnis-Präsentation zugleich der Abschluß 
der Studienarbeit bzw. in zwei Fällen die Präsentation der Diplomarbeit. 
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Fraxisübemahme 

Aufgrund der z.T. sehr guten Ergebnisse konnte in einigen Fällen die Frage gestellt 
werden, ob Pilotsysteme zu Praxissystemen ausgebaut werden sollen. Mangels eige- 
ner Personalkapazität in der Expertensystemgruppe mußten die Aktivitäten jedoch 
zunächst auf zwei Systeme beschränkt werden. 

Bei den Ausbauüberlegungen zum Praxiseinsatz war von vornherein klar, daß 
bestimmte Anwendungsgebiete nur auf dem Großrechner sinnvoll betrieben 
werden konnten. Bei Systemen, die auf dem PC bleiben konnten, wurde die 
Hardware z. T. als zentrales Problem gesehen. Da die Entwicklungen bislang auf 
einem Macintosh erfolgt waren, wurde mehrfach die Forderung nach anderer 
Hardware gestellt. Diese Forderungen waren mit einer Ausnahme völlig 
unbegründet, da es sich um stand-alone-Systeme handelte, die auch aus 
organisatorischen Gründen nicht auf vorhandener Hardware betrieben werden 
konnten. Dennoch waren umfangreiche Abstimmungsarbeiten mit der für 
technische Geräte zuständigen Abteilung erforderlich. Ausgangspunkt für diese 
Arbeiten war der Tatbestand, daß hier Anwendungssysteme auf nicht üblicher 
Hardware eingesetzt werden sollten. Kompatibilitätsüberlegungen waren im 
konkreten Fall zwar nicht aktuell, wurden jedoch gelegentlich in den Vordergrund 
gehoben. 

In anderen Fällen zeigte sich, daß Fachabteilungen zunehmend Bereitschaft für die 
Übernahme neuer Hardware- /Software-Kombinationen erkennen ließen. Zur 
Ergänzung dieser Bemühungen wurde ein weiteres Projekt mit Studenten initiiert: 
2 Studenten erhielten die Möglichkeit, ein bereits auf dem Macintosh realisiertes 
Pilotsystem mit derselben Shell und möglichst unverändert auf einem MS-DOS- 
Rechner zu realisieren. Es zeigte sich erwartungsgemäß, daß die grafischen Möglich- 
keiten von allen Endbenutzern als besonders vorteilhaft angesehen wurden. In- 
zwischen sind diese Möglichkeiten auch auf MS-DOS-Rechnern gegeben. 
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Im Falle des Leasing-Systems wurde ein umfangreicher Praxistest durchgeführt. Zu 
diesem Zweck wurden 20 Kundenbetreuer mit dem System konfrontiert. Die Ergeb- 
nisse wurden mittels Fragebögen zusammengestellt und für eine Korrektur des 
Systems ausgewertet. 

Für die tatsächliche Übernahme eines Expertensystems in die praktische Alltagsar- 
beit einer Abteilung waren noch zusätzliche Fragen zu klären. Wie können War- 
tungsarbeiten bzw. Erweiterungen durchgeführt werden? Wer übernimmt die Pfle- 
ge der Wissensbasen? Als besonders schwierig erwies sich zunächst die Ab- 
schätzung des Aufwandes. Grundsätzlich gehen wir inzwischen davon aus, daß 
Expertensysteme "pflegeaufwendiger" sind als herkömmliche EDV-Systeme. Der 
Umfang des jeweiligen Aktualisierungsaufwandes ist möglicherweise gering, dafür 
ist aber quasi ein permanenter Änderungs- bzw. Aktualisierungsprozeß gegeben. Die 
Frage, wer Änderungen durchführen soll bzw. kann, mußte zunächst dahingehend 
beantwortet werden, daß dies b.a.w. nur von Expertensystemspezialisten möglich ist. 
Erst zu einem späteren Zeitpunkt kann daran gedacht werden, daß gewisse 
"elementare" Änderungen und Erweiterungen in den jeweiligen Fachabteilungen 
selbst erbracht werden können. 



Experten und Entwickler 

Über Experten und Entwickler im Zusammenhang mit Expertensystemen ist eine 
umfangreiche Literatur verfügbar; es gibt zahlreiche Empfehlungen für eine optima- 
le Zusammenarbeit und geeignete Vorgehensweisen für die Gestaltung des Entwick- 
lungsprozesses. Die Erfahrungen in der WestLB zeigen sehr unterschiedliche Rollen 
von Experten und Entwicklern. Dies mag z. T. dadurch bedingt sein, daß für mehre- 
re Pilotsysteme Studenten und eben keine professionellen Systementwickler mit 
Erfahrung eingesetzt wurden. 

Zunächst mußte geklärt werden, was unter einem Experten verstanden werden soll. 
Es bestand schnell Übereinstimmung dahingehend, daß nicht unbedingt dann von 
einem Experten gesprochen werden muß, wenn das "Expertenwissen" auch aus ent- 
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sprechenden Lehrbüchern beschafft werden kann. Ein Experte ist grvmdsätzlich ein 
Mitarbeiter mit Spezialwissen, das sich durch Erfahrung über die Lösung komplexer 
Probleme und Tendenz zur Einmaligkeit auszeichnet. Es handelt sich oft um einen 
Unternehmensexperten. Das unternehmensspezifische Wissen ist in der Regel von 
erheblicher strategischer Bedeutung. 

Bei der Entwicklung und praktischen Arbeit mit Expertensystemen zeigten sich 
Experten zwischen Lethargie und Euphorie; es waren die imterschiedlichsten 
Schattierimgen des Verhaltens erkennbar. So ist beispielsweise auch der Extremfall 
des "Nicht-Experten" zu nennen. In diesem Fall wird eine Person als Experte 
bezeichnet, die nach den ersten Diskussionen erkennen läßt, daß sie praktisch kein 
Experte ist. Varianten dieses Expertentypen sind der "Nur-so-Experte", der glaubt, 
eine Sache sicher zu beherrschen; er nimmt an, daß eine bestimmte Aufgaben- 
stellung nur auf seine Weise und in keiner anderen Form gelöst werden kann. 
Demgegenüber steht aber die Tatsache, daß sich bei intensiverer Beschäftigung mit 
dem System Ungereimtheiten ergeben und eine schlüssige Vorgehensweise 
gefunden werden muß. 

Der "Das-geht-nicht-Experte" ist von der Einstellung geprägt, daß bestimmte, 
nämlich gerade die vom Expertensystem abzudeckenden Aufgaben, nicht von 
einem Computer übernommen werden können. Teilweise spielt auch hier noch die 
sog. Angst vor dem Computer herein. Der Experte glaubt möglicherweise auch, 
seinen Status als Experte an den Computer zu verlieren. 

Der "Sie-können-jetzt-eingeben-Experte" hat die Zusammenarbeit mit dem 
Wissensingenieur gründlich mißverstanden. Nachdem man mit ihm vereinbart 
hat, daß er seine Vorgehensweise im Anwendungsfall erläutern und ggfs, ein paar 
Notizen dazu machen möge, meldet er sich nach einiger Zeit wieder und teilt mit, 
daß er jetzt alles aufgeschrieben habe imd daß man dies jetzt in den Computer 
eingeben könne. 

Der ’Weiß-nicht-Experte" möchte grundsätzlich ein Expertensystem unterstützten, 
glaubt aber, entweder nicht zu wissen wie er selbst vorgeht, bzw. bestimmte Auf- 
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gaben erledigt. Zumindest ist er davon überzeugt, daß er nicht beschreiben kann 
wie er Probleme löst. Eine Abschwächung dieses Expertentypen ist der "Vielleicht- 
Experte". Er will zumindest versuchen, seine Aktivitäten zu formulieren. 

Der "Hoffentlich-ist-es-richtig-Experte" ist ein besonders interessanter Typ. Dieser 
Experte weiß sehr wohl wie er seine Arbeit macht, kann die Vorgehensweise auch 
gut beschreiben; er hat aber Sorge, daß seine Vorgehensweise keine Zustimmung 
findet. Im konkreten Fall der Präsentation eines Pilotsystems löste sich der Experte 
erst in dem Moment von seiner Anspannung, als sein Vorgesetzter bescheinigte, 
daß das System sehr gut sei xmd eine saubere und sorgfältige Analyse erkennen 
lasse. 

Die Zusammenstellung eines Teams von Experten ist die Konsequenz aus den oben 
beschriebenen Situationen. Mehrere Experten arbeiten dabei erfolgreich zusammen. 
Teamarbeit zur Darlegung des Expertenwissens konnte im Hause der WestLB 
mehrfach gewählt werden. Sie kommt der Idealvorstellung vom Experten am 
nächsten, weil hier eine Konsenzbildung bei der Wissenserhebung in sehr frühem 
Stadium und ständig möglich, wenngleich nicht immer einfach ist. In anderen 
Fällen, wie die angeführten Typen von Experten erkennen lassen, ergeben sich 
dagegen z.T. erhebliche Probleme und Risiken. Ein Expertensystem sollte, sofern 
möglich, generell akzeptiertes bzw. akzeptierbares Wissen enthalten. Konsenz- 
bildung ist daher in manchen Fällen unabdingbar. In diesem Fällen sollte dann 
auch eher von Unternehmenswissen als von Expertenwissen gesprochen werden. 

Als Wissensingenieur wird derjenige bezeichnet, der das Expertenwissen erhebt, 
strukturiert, repräsentiert und implementiert. Vielfach werden diese Personen als 
die eigentlichen Entwickler eines Expertensystems bezeichnet, wenngleich dies im 
Kern nicht richtig ist. Von einem Expertensystementwickler wird selbstverständlich 
erwartet, daß er sorgfältig prüft, ob eine Wissenserhebung noch zu akzeptierbaren 
Vorgehensweisen führen kann. Die Gefahr einer Fehlentwicklung ist jedoch bei 
Expertensystemen grundsätzlich nicht so groß wie bei konventionellen Systemen, 
da hier eine ständige Korrektur vom Entwicklungsprozeß her grundsätzlich 
möglich ist und ggfs, auch angestrebt werden muß. 
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An den Wissensingenieur sind in der Regel hohe Anforderungen zu stellen: Er 
benötigt neben seinem Fachwissen 

- eine hohe Auffassungsgabe, da er sich zur erfolgreichen Wissenserhebung 
intensiv und schnell in neue Problemstellungen einarbeiten muß, 

- Profil als Persönlichkeit, um akzeptiert zu werden und 

- die Fähigkeit, die unterschiedlichen Sprachebenen zwischen EDV-orientiertem 
Fachwissen und geschäftsorientiertem Expertenwissen zu überbrücken. 

Die versuchte Typisierung der Experten und die kurze Beleuchtung der Rolle des 
Entwicklers soll veranschaulichen, welche z.T. äußerst komplexen und psycholo- 
gisch brisanten Aufgabenfelder von einem Wissensingenieur angesprochen werden 
müssen. Die Erfahrung unseres Hauses zeigt, daß die Rolle des Entwicklers in aller 
Regel unterschätzt wird. Dies gilt gerade für die Konsenzfindung: Je größer die 
Anwenderzahl eines Expertensystems ist, desto eher ist der Entwickler hinsichtlich 
seiner Fähigkeit zur Konsenzbildung gefordert. 



Weiterentwicklung 

Die Zusammenarbeit mit Studenten auf dem Gebiet der Expertensystementwick- 
lung in der WestLB muß grundsätzlich als erfolgreich, wenngleich als aufwendig 
bezeichnet werden. Einige der entwickelten Prototypen wurden bzw. werden zu 
Praxissystemen weiterentwickelt. Da frühzeitig Wert auf geeignete Publikation im 
eigenen Hause gelegt wurde, waren alle Entwicklungen bekannt und es kamen 
Vorschläge für weitere Systeme aus verschiedenen Bereichen. Gleichzeitig wuchs 
die Bereitschaft zu größeren Investitionen in diese Entwicklungen. Die neuen 
Impulse konnten allerdings nicht immer aufgegriffen werden, da inzwischen eine 
Personalknappheit auf dem Gebiet der Expertensysteme eingetreten war. 

Als besonders ergiebig für den Prozeß der Zusammenarbeit mit Fachabteilungen hat 
sich die Möglichkeit erwiesen, mit einer Expertensystem-Shell in äußerst kurzer 
Zeitspanne zu ersten vorzeigbaren Ergebnissen zu kommen. Dabei ist der Experten- 
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systemgruppe immer öfter eine neue zusätzliche Rolle zugeschrieben worden: Der 
Knowledge-Engineer wird zum Organisator, Integrator und zum Konsenz- 
vermittler. Derartige Aufgaben können auch in Zukunft nur dann erfüllt werden, 
wenn eine geeignete Unterstützung "von oben" vorhanden ist. Die Art der heute 
erforderlichen Unterstützung unterscheidet sich deutlich von der in der 
Anfangsphase: Benötigt werden finanzielle Zusagen für konkrete Praxisprojekte, die 
ausreichende Verfügbarkeit von Experten und insbesondere die Bestätigung, daß der 
eingeschlagene Weg der Realisierung von Expertensystemen für die Unter- 
nehmung von Bedeutung ist. 

Als klassische Bremse für die Weiterentwicklung hat sich naturgemäß das Thema 
Kosten herausgestellt. Die ersten Überlegungen und Pilotsysteme erfolgten im 
Rahmen eines allgemeinen Forschungs- und Entwicklungsauftrages. Daher war 
von Seiten der beteiligten Fachabteilungen nur der entsprechende Personaleinsatz 
einzuplanen. Da die Phase des Kennenlernens dieses neuen Entwicklungsbereiches 
jedoch abgeschlossen ist, müssen die Kosten für weitere Entwicklungen voll von 
den hausinternen Auftraggebern übernommen werden. 

Die heute entwickelten Pilot- und Praxissysteme sind wesentlich weiter ausgereift 
als zu Beginn der Beschäftigung mit dem Thema Expertensysteme. Zum Teil war 
dies auftragsbedingt, denn es wurden primär Einführungssysteme oder Schulungs- 
systeme geschaffen. Man sah sich das System ein paarmal an, um einen grund- 
sätzlichen Eindruck zu gewinnen und über weitere Systeme bzw. Systemvarianten 
zu entscheiden. Von Einsatz oder Nutzungshäufigkeit konnte bei Demonstrations- 
systemen keine Rede sein. Sie waren primär Basis oder auch nur Anregung für die 
Schaffung praxisrelevanter Systeme. Dies dürfte auch heute noch für viele in der 
Literatur angeführten sog. Praxissysteme gelten. 

In der WestLB sind heute Expertensysteme für folgende Anwendungsbereiche in 
Entwicklung bzw. im Praxiseinsatz: Auslandsmarktberatung, Förderprogramm- 
beratung für verschiedene Zielgruppen, Leasingberatung. Dabei zeigt sich auch, daß 
OR-Verfahren, die in der Vergangenheit relativ schwer durchzusetzen waren, durch 
die neuen technologischen Möglichkeiten einer intensiven Nutzung zugeführt 
werden können. 
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Die Ziele der Entwicklung von Expertensystemen haben sich nach unseren Erfah- 
rungen ebenfalls verändert. Zunächst ging es ausschließlich um den Einstieg, d.h. 
das Kennenlernen einer neuen Technologie. Detailliertere Ziele wurden erst nach 
den ersten Erfahrungen definiert. Hierzu gehört die Standardisierung der Problem- 
lösung und der Beratungsleistung, die Erhöhung der Entscheidungsqualität, die 
Sicherung des Expertenwissens, die Produktivitätssteigerung durch Beschleimigung 
der jeweiligen Prozesse, die Einarbeitung neuer Mitarbeiter und natürlich die Ent- 
lastung des Experten. Ganz allgemein stellen die Expertensysteme eine weitere Be- 
reicherung der computergestützten Möglichkeiten zur Problemanalyse und Ent- 
scheidungsfindung dar. 

Mit dem Ausbau und der breiteren Konzeption neuer Expertensyteme sind die An- 
forderungen der Fachabteilungen weiter gestiegen. Die Expertensystemgruppe muß 
auch auf Fragen nach Datenbanken, ihrer Konzeption, Realisierung und Integration 
antworten. Die Integration von Expertensystemen in die bestehende DV-Umgebung 
ist erwünscht; sie werden somit ganz "normale” Systeme der Informationsverar- 
beitung werden. Bereits heute ist eine deutliche Überlappung beider Systemarten 
festzustellen. 

Die bisherigen Entwicklungen im Hause der WestLB wurden ausschließlich auf PCs 
durchgeführt. Zukünftige Systeme werden sowohl auf dem PC als auch auf Groß- 
rechnern verfügbar sein. Dazu wurde ein Projekt zur Auswahl einer Großrech- 
ner-Shell gestartet und inzwischen abgeschlossen. Neue Expertensysteme sind für 
den Großrechner vorgesehen; ihre Realisierung muß durch Softwarehäuser 
unterstützt werden. 



Schlußbemerkxmgen 



Es ist keine neue Erkenntnis, daß innovative Informatik nur dann in ein 
Unternehmen gebracht und effektiv umgesetzt werden kann, wenn die entspre- 
chenden Voraussetzungen gegeben sind. Dazu gehört nicht nur die Bereitschaft zur 
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Kostenübernahme, sondern insbesondere eine grundsätzliche Aufgeschlossenheit 
gegenüber derartigen Entwicklungen. Die Zusammenarbeit mit Hochschulen bietet 
sich beim Einstieg in neue Bereiche grundsätzlich an, insbesondere dann, wenn 
diese neuen Bereiche noch keine ausreichende Praxisreife bewiesen haben. Auf 
diese Weise können leicht neue Erkenntnisse für die Praxis gewonnen werden. 
Möglicherweise sind Hochschulabsolventen auch an einer späteren Arbeit in dem 
jeweiligen Unternehmen interessiert. Die Zusammenarbeit mit Hochschulinsti- 
tuten ist somit zweifellos auch unter dem Aspekt der Personalakquisition zu sehen. 
Der Aufwand seitens des Unternehmens, hier der WestLB, der insbesondere durch 
die permanente Betreuung von Studenten gegeben ist, muß dem allerdings 
gegenüber gestellt werden. 

Aus den gegebenen Erfahrungen können ebenfalls Forderungen an Hochschulen 
abgeleitet werden. Expertensysteme sind typische Einsatzgebiete für Informatiker, ob 
als Kerninformatiker, Wirtschaftswissenschaftler oder Hochschulabsolventen 
anderer Ausbildungsrichtungen mit entsprechendem Nebenfach bzw. als Wirt- 
schaftsinformatiker. Die bei Studenten beobachteten Kenntnisse ließen durchweg 
eine fundierte Ausbildung erkennen. Zentraler Punkt ist jedoch das Vermitteln und 
Umsetzen neuer Ideen und Ansätze. Der Erfolg der Bemühungen um Fortschritte 
auf dem Gebiet der innovativen Informatik in der Praxis ist oft eine Frage der 
Persönlichkeit der Beteiligten. Gefordert sind insbesondere Fähigkeiten im Bereich 
der Kommunikation, um das erwähnte Sprachebenenproblem zu lösen. Allerdings 
dürfte dieses Ausbildungsfeld kaum von den Hochschulen übernommen werden 
können. 

Auch an die Praxis lassen sich Forderungen aus den bisherigen Erfahrungen ablei- 
ten. In erster Linie muß das unternehmenspolitische Klima gut sein für 
Entwicklungen auf dem Gebiet der innovativen Informatik. Informatik bedeutet 
jedoch für die meisten Mitarbeiter in der Praxis das Nutzen von EDV-Systemen am 
Arbeitsplatz. Nur wenn diese Systeme akzeptiert sind, ist die Aufgeschlossenheit für 
Neuentwicklungen entsprechend groß. Zu den Forderungen an die Praxis gehört 
aber auch, daß ein hinreichender Ereiraum für Forschung und Entwiddimg gegeben 
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sein muß. Innovative Informatik darf nicht die zu Recht bestehenden 
EDV-Vorschriften als Hemmschuh mitschleppen. Vorschriften sind sirmvoll und 
erforderlich, im Bereich der Erprobung neuer Techniken köimen sie eine starke 
Innovationsbremse sein. Sobald diese anspricht, kann das Engagement der 
Beteiligten stark beeinträchtigt werden. Frühzeitiger Einstieg in die Experten- 
systemtechnologie mit sirmvollen Werkzeugen einer gewissen Leistungsfähigkeit 
erforderte im Fall der WestLB die Nutzung neuer Hardware. Zu strenge 
Restriktionen beim Hard- und Softwarekauf sind ein Hemmschuh für die 
Entwicklung. Das Bewußtsein für die Notwendigkeit von Bemühungen um 
iimovative Informatik in der Praxis muß weiter verstärkt werden. Dies dürfte eine 
gemeinsame Aufgabe von Hochschule und Praxis sein. 
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Zusammenfassung 

Die Konzeption und Realisierung von Anwendungssystemen geht von der Prämisse aus, 
daß die in Frage kommenden Problemlösungsmethoden eines Fachgebiets hinreichend 
bekannt und überprüft sind. Insbesondere wird davon ausgegangen, daß im Rahmen des 
Fachkonzepts die "beste" Methode ausgewählt und anschließend in einem DV-Konzept 
abgebildet wird. Diese Vorgehensweise verkennt, daß es in Praxisprojekten oft alterna- 
tive Vorgehens weisen zur Problemlösung geben kann und daß die Wahl einer konkreten 
Problemlösungsmethode zu Beginn eines Entwicklungsvoiiiabens die Gefahr einer sub- 
optimalen Software-Lösung beinhaltet. Aus diesem Grund wird eine Vorgehensweise 
vorgeschlagen, welche die Realisierung alternativer Problemlösungsmethoden vorsieht. 
Die objektorientierte Programmierung wird als technische Basis vorgestellt, auf der 
aufbauend diese Vorgehensweise wirtschaftlichen Erfolg verspricht. Die Darstcllimg 
erfolgt am Beispiel einer Projektmanagement-Software im Bereich der Netzplantechnik. 

Schlüsselwörter: Alternative Problemlösungsmethoden, Software Engineering, 

Objekt-orientierte Programmierung, Netzplantechnik, Projektma- 
nagement 
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Abstract 

The conception and rcalization of applications in a given domain are based on thc pre- 
misc that the methods of problem solving are well known and valid. Proceeding on this 
assumption the best method can be choosen for building the EDP-concept. This model 
is not leflecting the fact that in real-life projects altemate methods of problem solving 
may exist and that the fixing of one alternative often leads to suboptimal Software Solu- 
tions. For this reason a procedure is reconunended, in which all altemate problem sol- 
ving methods have to be implemented. The object-oriented programming is the techni- 
cal base for the expected benefits. As an example of a Software designed that way an 
implementation of network-technique Software in the field of project-management is 
shown. 

Keywords: Altemate problem solving methods, Software engineering, object- 

oriented programming, network-technique, project management 



1. Problemstellung 

Die Begriffe Künstliche Intelligenz-Forschung und Expertensystemtechnik waren die 
Schlagworte der achtziger Jahre. Forschungsergebnisse in den USA sowie japanische 
Projektankündigungen zum 5. Computergenerationsprojekt wirkten nachhaltig auf Ein- 
richtungen in Wissenschaft und Praxis. Es entstand eine Fülle von Forschungsprojekten, 
die, speziell auf dem Gebiet der Expertensysteme, die Einsatzmöglichkeiten und Gren- 
zen dieser neuen Technik ausloten sollten. Viele dieser Projekte untersuchten Fragestel- 
lungen der Optimierung betriebswirtschaftlicher Kenngrößen auf einem Computer. 

In vielen dieser Vodiaben stand und steht die Frage zur Diskussion, mit welchen 
Methoden und Verfahren einerseits und nüt welcher Implementiemngstechnik anderer- 
seits eine Problemlösung erreicht werden soll. Beschränkt man sich auf den Bereich der 
betriebswirtschaftlichen Anwendungen, so stehen neben den Verfahren der Künstlichen 
Intelligenz-Forschung ebenso Verfahren der klassischen Entscheidungstheorie, des 
Operations Research, u.a. zur Disposition. Es scheint nicht gelungen zu sein, zweifels- 
frei die Frage zu klären, welches Problem mit welcher Problemlösungsmethode und mit 
welcher Problemlösungstechnik gelöst werden soll. Dabei sei Methode als planmäßiges 
Vorgehen definiert, welches aufbauend auf Handlungsanweisungen dem Erreichen 
eines wissenschaftlichen oder praktischen Ergebiüsses dient. Der Begriff Problemlö- 
sungstechnik bezieht sich im wesentlichen auf die Umsetzung einer Methode auf einem 
Computer. 
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Gegenstand dieses Aufsatzes ist die Frage nach dem Einsatz von Problemlösungsme- 
thoden- und techniken und des Managements der dabei auftietenden Probleme. Es soll 
gezeigt werden, daß die objektorientierte Programmierung es erlaubt, Anwendungssy- 
steme zu konstruieren, die den nachträglichen Austausch oder die Variationen der Pro- 
blemlösungsmethoden ermöglichen. Das Ziel ist die Darstellung evolutionärer Vorge- 
hensweisen der Problemlösung durch die Abbildung alternativer und konkurrierender 
Varianten in Fällen, in denen keine eindeutige Vorgehensweise zu Beginn der Überle- 
gungen vorhanden ist. 

Hierzu wird zunächst der Begriff DV-Projekt auf diejenigen Projekte eingeschränkt, in 
denen eine solche Vorgehensweise sinnvoll ist. Die Charakteristika solcher Projekte 
werden dargestellt und anhand zweier Beispiele verdeutlicht. Im Anschluß daran wer- 
den die Möglichkeiten der objektorientierten Programmierung so dargestellt, wie sie 
sich den Wissenschaftlern und Praktikern heute darbieten. Im nachfolgenden Abschnitt 
werden Hypothesen aufgestellt, mit denen sich der Artikel dann aufgrund von Pausibili- 
tätsüberlegungen und eigenen Erfahrungen der Autoren in mehreren Projekten ausein- 
andersetzt. Den Schluß des Aufsatzes bildet die Reflexion, inwieweit sich diese Dis- 
kussion in den übergeordneten Zusammenhang des Software-Engineering einbettet. 



2. Klassifikation von Projekten 

Die Konzeption und Durchführung von Systemerstellungsleistungen in den Unterneh- 
men erfolgt im wesentlichen in den zwei Varianten Liiüenorganisation und Projektor- 
gaiüsation. Während in der Linienorganisation vorwiegend Aufgaben geringeren 
Umfangs und insbesondere die Wartung und Pflege bereits existierender DV-Anwen- 
dungen übernommen werden, ist in den vergangenen Jahren zunehmend zu beobachten, 
daß neue Systeme in der Projektorganisationsform erstellt werden. Ein Projekt sei hier- 
bei definiert als die Gesamtheit aller Maßnahmen und Aktivitäten, deren gemeinsames 
Ziel darin besteht, einen ganz bestimmten, wohldefinierten Gegenstand innerhalb einer 
im voraus festlegbaren Zeitspanne mit Hilfe einer zieladequaten Aufbau- und Ablaufor- 
ganisation, unter Verwendung geeigneter Hilfsnüttel und Techniken und im Einsatz 
quantitativ und qualitativ ausreichender Ressourcen von kompetenten Stellenoiganisa- 
tionseinheiten zu erstellen. [Bessai 85]. Ein wesentliches Argument für die Projektor- 
ganisationsform ist, daß heutzutage vermehrt Spezialisten aus DV- und Fachabteilungen 
zur Lösung eines speziellen Problems herangezogen werden müssen. Diese Spezialisten 
sind rar und danüt teuer, sodaß eine optimale Ausnutzung der Ressource nur durch den 
multiplen Einsatz in verschiedenen Projekten erfolgen kann. Im Rahmen dieses Auf- 
satzes soll zunächst eine Klassißkation von EDV-Projekten nach ihrer Aufgabenstel- 
lung vorgenommen werden. Aus inhaltlicher Sicht können prinzipiell drei Projektarten 
unterschieden werden: 
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a. Projekte zur Einführung von Standardsoftware 

Die Einführung von Standardsoftware gestaltet sich oft schwierig. Gerade bei der 
Einführung von Großrechnersoftware ist es oftmals zwingend notwendig, Anpas- 
sungen an betriebliche Gegebenheiten vorzunehmen. Die Einführung von Stan- 
dardsoftware erfolgt meist in Projektorganisationsform. Herausragendes Merkmal 
der Standardsoftware ist, daß sie allgemein anerkannte und allgemeingültige 
Methoden zur Lösung bestimmter betriebswirtschaftlicher Probleme unterstützt. 
Ein Beispiel ist die Einführung einer Standardkostenrechnungssoftware, welche 
eine oder mehrere Methoden der Betriebswirtschaftslehre zur Verrechnung und 
Transparentmachung von Kosten beinhaltet. Ziel bei der Einführung von Stan- 
dardsoftware ist in einem solchen Fall, nicht eigenständige, betriebsspezifische 
Entwicklungen und Implementierungen von Kostenrechnungsmethoden leisten zu 
müssen, sondern der Unternehmung vielmehr allgemeingültige Verfahren der 
Betriebwirtschaftslehre verfügbar zu machen. 

b. Projekte zur Implementierung bekannter Methoden 

Eine Vielzahl von Projekten hat sich in der Vergangenheit damit beschäftigt, 
einer Unternehmung durch die Implementierung eigenerstellter Software eine 
bereits bekannte Methodik zur Verfügung zu stellen. Ein Beispiel ist ein Transak- 
tionssystem zur Buchung von Passagieren einer Fluggesellschaft. Obwohl die 
Methoden und Algorithmen einer solchen Anwendung bestens bekannt sind, ent- 
scheiden sich Unternehmen aus verschiedenen Gründen für die Individualerstel- 
lung der Software. Diese Entscheidung wurde in der Vergangenheit oftmals durch 
ein unzureichendes Angebot an Standardsoftware hervorgerufen. Desweiteren 
wird oft mit der individuellen Problemsituation des Unternehmens argumentiert. 
Kennzeichnend für diese Art EDV-Projekt ist, daß sie zwar einen sehr großem 
Umfang, gemessen in Mitarbeiteraufwand, aufweisen kann, daß aber nur im 
beschränkten Maße eine unbekannte Problemstruktur vorliegt. Das Projektrisiko, 
und damit im direkten Zusammenhang der Projektaufwand, wird sehr stark von 
der Größe der Anwendung, gemessen im Lines of Code, bestimmt. 

c. Projekte mit vorab unbekannten Problemlösungen 

Unter dieser dritten Kategorie von EDV-Projekten seien all jene Projekte subsu- 
miert, in denen der Versuch unternommen wird, Problemlösungen auf dem Com- 
puter zu implementieren, für die es bis dato keine anerkannten und allgemeingül- 
tigen Problemlösungsverfahren gibt. Die eingeschränkte Methodenverfügbarkeit 
kann dabei zum Beispiel daraus resultieren, daß in Zusammen-arbeit mit diesen 
Systemen Entscheidungen unter Unsicherheit getroffen werden müssen. In der 
Praxis kommt es darüber hinaus oft zu der Situation, daß auch die Mitbewerber 
keine fertige Lösung vorweisen können, sodaß für die Entscheidungen, welche 
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Vorgehensweise und welche Methoden gewählt werden sollen, kein Präzedenzfall 
existiert. Oft handelt es sich bei solchen Problemstellungen um Planungssysteme, 
in denen eine Fülle von Restriktionen den Planungs-erfolg beeinflußt. 

Im folgenden soUen Projekte untersucht werden, die den Kriterien des Punktes 3 ent- 
sprechen. Ausgeklammert Werden kleinere und mittlere Vorhaben, welche drei Mann- 
jahre Projektaufwand nicht übersteigen. Die Untersuchung der Frage, wie verschiedene 
Problemlösungsmethoden alternativ konkurrierend und gewinnbringend für das Unter- 
nehmen eingesetzt werden können, ist vor allem in Projekten mit mehr als drei Mann- 
jahren interessant. Hier ist zum einen der durch die parallele Untersuchung mehrerer 
Problemlösungen entstehende Mehraufwand prozentual gering. Zum anderen ist das 
Risiko bei der Auswahl einer falschen Problemlösungsstrategie jedoch umso größer. 
Die Aussage, daß immense Aufwendungen für Wartung und Pflege von Altsoftware in 
den Unternehmen ausschließlich auf fehlerhaftes Projektmanagement bzw. unstuktu- 
rierte Implementierungstechnik zurückzuführen sind, erscheint wenig pausibel. Ver- 
mutlich gibt es ebenso gravierende Fälle, in denen die gewählte Problemlösungsme- 
thode der Problemstellung nicht adäquat war. Dies hat dazu geführt, daß im Rahmen 
modifizierter Phasenmodelle exploratives Prototyping als Erstellungsmethoden ent- 
wickelt wurde (z. B. [Boehm 88]). 

Als eine typische Klasse von Problemstellungen, die in Projekten der Kategorie 3 
abgewickelt werden, sind Optimierungsprobleme zu sehen. Optimierungsprobleme 
zeichnen sich zwar meistens durch eine klare Zieldefinition aus, jedoch ist es oftmals 
schwer, die Menge der Restriktionen formal einwandfrei zu formulieren bzw. Unsi- 
cherheit, Risiko und vages Wissen adäquat abzubilden. Dieses wird in der Praxis oft- 
mals noch dadurch verstärkt, daß zur Problemlösung Einzelentscheidungen von Fach- 
experten nötig sind, welche in den Optimierungsprozeß eingebunden werden müssen. 
Die Wahl der Problemlösungsmethode erfolgt zu Beginn des Projekts in der Phase der 
Ideenfindung oder Grobkonzeption. Hier wird festgeschrieben, nach welcher Strategie 
das Optinüerungsproblem algorithmisiert und auf dem Computer zum Ablauf gebracht 
werden soll. Das Software-Engeneering schlägt hierzu in verschiedenen Varianten eine 
phasengestufte Vorgehensweise vor, welche zunächst die Konzeption und die Entwürfe 
vorsieht und erst anschließend die Implementierung. Dabei tauchen für den dritten Pro- 
jekttyp zwei gravierende Nachteile auf: 

Die Beantwortung der Frage, welche Problemlösungsmethode gewählt werden 
soll, ist ohne die Implementierung des fertigen Systems und seine empirische 
Überprüfung oftmals nicht möglich. Der fehlende exakte Beweis für die "richtige” 
Problemlösungsstrategie führt dazu, daß Annahmen getroffen werden, welche 
hinterher unter Umständen empirisch widerlegt werden können [Behrendt 90]. 
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Ein zweiter gravierender Nachteil ist, daß, gemessen in Lines of Ccxie, oftmals 
nur geringe Teile der späteren Software, die eigentliche Problemlösungsmethode 
beinhalten. Gerade dieser Nukleus des zu erstellenden Systems sollte aber zu 
Beginn des Projektes verstärkt überprüft werden. Weite Teile der Probleme der 
Softwarerealisation, wie z.B. Datenmanagement, Schnittstellenmanagement, 
Netzwerkmanagement und die Oberflächenstruktur des späteren Systems werden 
parallel zum Nukleus entworfen und behindern unter Umständen das Finden der 
optimalen Lösung. Diese Behinderung besteht im wesentlichen aus der Bindung 
der Mitarbeiterkapazität sowie der Fokussierung auf Implementierungsdetails, 
was die Relevanz des Nukleus nicht adäquat hervortreten läßt. Die Gefahr der 
Verkürzung der Problemlösung aus technischen Gründen ist hoch. 

Beide Nachteile sollen am Beispiel CARGEX deutlich gemacht werden. Es handelt sich 
hierbei um ein Projekt, welches an der Wissenschaftlichen Hochschule für Untemeh- 
mensführung Koblenz, Lehrstuhl für Betriebswirtschaft, insbesondere Wirtschafts- 
informatik und Informationsmanagement, in Zusammenarbeit mit der Deutschen Luft- 
hansa AG bearbeitet wurde [Wolf 90]. 

Das Problem der Optinüerung des Ertrags bei der Luftfrachtbeförderung besteht im 
wesentlichen in der Frage, wie aus einem einkommenden Strom von Frachtanfragen 
diejenigen ausgewählt und zur Beför-derung angenommen werden sollen, welche im 
Ergebnis den Ertrag optimieren. Das Problem der Luftfrachtoptimierung ist bislang in 
der wissenschaftlichen Literatur nicht geklärt [König 88]. Zwar existiert eine Vielzahl 
von Veröffentlichungen im Bereich Luftverkehr, welche sich im wesentlichen aber auf 
die Optimierung des Ertrags im Passagebereich konzentrieren [Etschmaier 74]. Bedingt 
durch die eindeutige Zuordnung von Passagieren zu Sitzplätzen schien diese Fragestel- 
lung mit Methoden des Operations Research in der Vergangenheit für die Luftfahrtge- 
sellschaften lösbar [Etschmaier 74] [Alstrup 86] [White 85]. 

In der Praxis sind vier Varianten zur Lösung des Luftfrachtoptimierungsproblems 
denkbar. Die erste und systemtechnisch triviale Variante besteht darin, jede vom Kun- 
den der Fluggesellschaft vorgenommene Anfrage durch eigens hierfür ausgebildete 
Luftfrachtexperten prüfen zu lassen, welche die Beförderung akzeptieren oder ablehnen. 
Weltweit ist dieses Verfahren so bei den meisten Luftverkehrsgesellschaften im Einsatz. 
Eine zweite Variante ist die Übertragung von Konzepten aus dem Passagebereich in den 
Luftfrachtbereich. So ist es denkbar, Kategorien von Luftfrachtsendungen, sogenannte 
Klassen, zu bilden, für welche nüt statistischen Methoden ein wahrscheinlicher Zulauf 
von Frachtsendungen prognostiziert werden kann. Diese Klassen, z. B. Standby-Fracht, 
Normalfracht , Spezialfracht usw. , werden in einer Voreinstellung für jeden Flug 
initialisiert und anschließend durch die automatisierte Annahme von Frachtsendungen 
gefüllt Dieses Verfahren entspricht im wesentlichen der Regelung im Passagebereich, 
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WO Teile der Flugzeugkabine bestimmten Beförderungsklassen zugeordnet sind. Die 
Entscheidung über die Zuordnung einer Frachtsendung zu einer Klasse orientiert sich 
dabei an den drei Maßgrößen Gewicht, Volumen und Ertrag. Eine dritte Variante für 
ein Luftfrachtoptinüerungssystem könnte ein Expertensystem sein, welches die Regeln 
des menschlichen Problemlösers automatisiert anwendet. Solche Regeln können sich z. 
B. auf Aspekte wie Kundenprioritäten, Sendungsprioritäten, gefährliche Güter und den 
Deckungsbeitrag beziehen [Bertsch 90]. Ziel eines solchen Ansatzes wäre es, das Pro- 
blemlösungsverhalten des Frachtexperten zu automatisieren, um ihn von Routinetätig- 
keiten zu entlasten. Eine vierte Variante ist die Modellierung des Luftfrachtoptinüe- 
rungsproblems mit Hilfe der Markov'schen Entscheidungstheorie [Wendt 90]. 

Alle vier Varianten haben die Optimierung des Ertrags zum Ziel. Jedoch unterscheiden 
sie sich erheblich im Hinblick auf die Problemlösungsstrategie, die Problemlösungs- 
technik und, daraus abgeleitet, im Prozeß der Problemlösung selbst. Die Frage, welche 
Lösungsvariante das Problem am besten löst, ist rein normativ nicht zu beantworten. In 
der Praxis der Luftfrachtoptinüerung existiert eine Fülle von Restriktionen und Aus- 
nahmeregelungen, die einen Vergleich der Verfahren z. B. unter rein mathematischen 
Gesichtspunkten unmöglich machen. Die Überprüfung der Problemlösungsstrategien 
könnte jedoch im Feldtest , d. h. im Einsatz aller vier Methoden mit anschließender 
Bewertung und Vergleich erfolgen. Dieses ist umso mehr zu empfehlen, wenn weitere 
Teile des Systems aus Hardware- und Software-Sicht identisch sind. So sind im Bei- 
spiel Luftfrachtoptinüerung die Datenbasis, die Schnittstellen sowie Teile der Oberflä- 
che mehrfach verwendbar. 

Am obigen Beispiel wird deutlich, daß in der Phase der Grobkonzeption eines Softwa- 
reprojekts Entscheidungen über eine Problenüösungsstrategie getroffen werden, die 
die Güte und spätere Akzeptanz des Systems nachhaltig beeinflussen. Die Entscheidung 
für eine konkrete Problemlösungsstrategie erfolgt dabei oftmals vor dem Hintergrund 
der Kalkulierbarkeit des Aufwands des Gesamtprojekts. So ist es unter Einbeziehung 
nur einer Variante durchaus möglich, den Projektumfang klar zu spezifizieren und mit 
Hilfe von bewährten Schätzverfahren den Projektaufwand zu quantifizieren. Im Ergeb- 
nis bedeutet dies jedoch nichts anderes als eine Verlagerung der Methodendiskussion in 
die 2Wamft. Für diese Vorgehensweise spricht oft die gegebene betriebliche DV-Infra- 
struktur. Die Machbarkeit einer Variantenkonzeption ist heute aufgrund mangelnder 
Verfügbarkeit von Werkzeugen auf den verschiedenen Rechnerplattformen nicht durch- 
gehend gewährleistet. 
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3, Objektorientierung beim Entwurf und der Implementierung betrieblicher 
DV-Systeme 

Im vorangegangenen Abschnitt wurde deutlich, daß die Exploration verschiedener 
Problemlösungstrategien sowie die schnelle Implementierung dieser Varianten auf den 
Erfolg eines DV-Projekts großen Einfluß haben kann. Zur Umsetzung dieser Forderung 
soll hier nun die Objektorientierte Programmiermethodik dargestellt werden. Ziel ist es, 
die Methoden und Techniken der Objektorientierung vorzustellen. 

Objektorientierung und Objektorientierte Systeme wurden bereits in den Anfängen der 
siebziger Jahre, bei der Firma Xerox im Rahmen des SMALLTALK-Systems erdacht. 
Ziel der damaligen Forschungsarbeiten bei Xerox war, einen Beitrag zur Verbesserung 
der Mensch-Maschine-Kommunikation zu leisten. Die Ideen, welche sich in der Ent- 
wicklung von SMALLTALK niederschlugen, wurden später in der Künstlichen Intelli- 
genz Forschung, und hier insbesondere bei Expertensystemen, von den Entwicklern von 
Expertensystem-Shells aufgegriffen. Es entstand eine Reihe von Prototypen, welche 
sich als Wissensrepräsentationsschema des Frame-Konzepts bedienten. Die zentrale 
Idee hierbei ist, die reale Welt möglichst 1:1 in einem Rechner abzubilden. Diese 
Abbildung im Rahmen der Wissensrepräsentation beinhaltet die Implementierung von 
Gegenständen, Ideen, Personen, etc. als Objekte in einem Computeiprogramm. Durch 
die Entwicklung im objektorientierten Modell sollen reale Objekte und ihre Beziehun- 
gen untereinander im Rechner nachgebaut werden. Ein Objekt beinhaltet alle Daten und 
Strukturen, welche es spezifizieren. Im einzelnen sind dies (siehe [Meyer 88] [Cox 87] 
[Booch 90]): 

der Objektname als Zugriffsschlüssel 
die Attributliste des Objekts 
die Attributwerte 

Informationen über Verknüpfungen zu anderen Objekten 

Die Modellierung von Objekten beinhaltet die Modellierung von Struktur und Verhal- 
ten. Es muß demzufolge zwischen struktureller Objektorientiertheit und verhaltensmä- 
ßiger Objektorientiertheit unterschieden werden. Volle Objektorientierung liegt immer 
dann vor, wenn sowohl die Anforderung des strukturellen wie auch der verhaltensmäßi- 
gen Objektorientierung erfüllt sind [Dittrich 90]. 

Von struktureller Objektorientiertheit kann immer dann ausgegangen werden, wenn 
Objekte in Form von Klassen-Instanzen-Hierarchien gebildet werden. Diese Hierarchi- 
sierung erfolgt entweder Bottom-up, d.h. über die Aggregation von Eigenschaften, 
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welche einer Vielzahl von Objekten zugeordnet werden können, oder Top-down durch 
die schrittweise Verfeinerung von Klasseninformationen bis hin zu den konkreten Aus- 
prägungen einer Klasse, den Instanzen. 

Das folgende Beispiel soll die Vorgehens weise beim Entwurf objektorientierter Daten- 
strukturen verdeutlichen. Auf der obersten Stufe einer Objekthierarchie steht immer 
eine Klasse. Der Begriff Klasse bezeichne: ”the technical term that will be applied in 
Object-Oriented languages to describe such sets of data structure characterized by com- 
mon properties.” [Meyer 88, Seite 52] Als Beispiel sei hier die Klasse "Vorgänge eines 
Netzplans" gegeben, welche als Attribute die klassifizierenden Merkmale von Vorgän- 
gen enthält. Z.B. können dies die Vorgangsnummer, ein Vorgangskommentar, usw. 
sein. Im Sinne der Top-down Verfeinerung der objektorientierten Datenstruktur können 
nun Subklassen gebildet werden, welche über zusätzliche Attribute verfügen. Im vorlie- 
genden Beispiel seien dies die Subklassen Standard-Vorgänge und individuelle Vor- 
gänge. Diese Unterscheidung trägt dem Umstand Rechnung, daß das zu konzipierende 
System über Standardvarianten von Netzplänen verfügen soll, welche dem einzelnen 
Projektleiter zu seiner Unterstützung angeboten werden. Ein konkreter Vorgang mit 
seinen Daten wird nun durch die Instanziierung einer der beiden Subklassen erzeugt. 
Kennzeichen des objektorientierten Modells ist es, daß dabei die Eigenschaften von 
höheren Klassen auf untergeordnete Klassen und Instanzen vererbt werden. Die nach- 
folgende Abbildung 1 zeigt die Vererbungshierarchie dieses Beispiels. 

Eine weitere, wichtige Forderung des objektortientierten Modells ist, daß die Merk- 
malsausprägung, d.h. die Werte von Attributen von Instanzen, nicht atomar sein müs- 
sen. Es können vielmehr Listen, verschachtelte Listen und komplexe Objekte als Werte 
von Attributen zugelassen werden. Im Beispiel könnte der Wert des Attributs 
"Nachfolger eines Vorgangs" mehrere Vorgänge beschreiben, welche zu dieser Instanz 
eine Nachfolge- Anordnungsbeziehung haben. Das Vererben von Objekteigenschaften 
hat eine Reihe von Vorteilen. Herausragende Eigenschaften ist, daß Objektmerkmale 
nur einmal definiert und über die Klassen-Instanzenbeziehung vererbt werden können. 
Dies erleichtert die Strukturierung der Datenbasis und den mentalen Zugang des Ent- 
wicklers und des Anwenders zum System [Rosson 89]. Ferner können durch diese klare 
Strukturierung der Objekte Fehler im Entwurf und Versäumnisse bei der Datenmodel- 
lierung weitestgehend verhindert werden. Ein weiterer Vorteil ist, daß in einem objekt- 
orientierten System sehr schnell "Standards" als Klasse abgebildet werden können. 
Sonderfälle, Ausnahmen oder ähnliches können durch Modifikationen in Unterklassen 
oder Instanzen abgebildet werden. Somit wird der menschlichen Vorgehens weise bei 
der Problemlösung entsprochen. Zunächst wird das Allgemeine und dann das Spezielle 
gelöst. Nicht zuletzt ist ein solchermaßen entworfenes Modell modular, was die Aus- 
tauschbarkeit einzelner Komponenten und damit die Flexibilität der Software direkt 
beeinflußt. 
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Abbildung 1: Eine beispielhafte Objekthieraichie 

Von verhaltensmäßiger Objektorientiertheit kann immer dann ausgegangen werden, 
wenn in einem Objekt Eigenschaften und Funktionen miteinander verschachtelt werden. 
Dies bedeutet, daß Daten und ihre zugehörigen elementaren Funktionen gemeinsam 
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verwaltet werden. Über diese Funktionen können Objekte miteinander kommunizieren. 
Der zentrale Mechanismus der Kommunikation wird durch das "Message Passing" 
unterstützt. Dieses bedeutet, daß sich Objekte untereinander Nachrichten zusenden kön- 
nen. Die Menge der Nachrichten, welche ein Objekt verarbeiten kann, ist sein Protokoll 
[Stoyan 84]. Alle Zugriffe auf die internen Strukturen eines Objektes erfolgen über 
diese uniforme Kontrollstruktur. Beim Nachrichtenaustausch in objektorientierten 
Systemen sind dabei grundsätzlich zwei Fälle zu unterscheiden: 

Das aufrufende Objekt sendet dem aufgerufenen Objekt eine Nachricht (nüt oder 
ohne Parameterübergabe) und verharrt in seinem Zustand bis zur Rückgabe eines 
Ergebnisses. 

Das aufrufende Objekt übergibt dem aufgerufenen Objekt eine Nachricht (mit 
oder ohne Parameterübergabe) und setzt sofort danach seine eigene Verarbeitung 
fort. Der letzte Fall des asynchronen Aufrufs kann zur Entwicklung paralleler 
Prozesse genutzt werden. 

Kommen in einem Modell die Elemente strukturierte und verhaltensmäßige Objekt- 
orientiertheit zusammen, so wird von einem vollobjektorientierten System gesprochen. 
Dies bedeutet, daß die Funktionen der Objekte in den Klassen genauso behandelt wer- 
den wie die Datenstrukturen. Die Funktionen der Klassen werden, ebenso wie die 
Datenstrukturen, auf die untergeordneten Subklassen oder Instanzen vererbt. Die volle 
Objektorientierung vereinigt die Datenstruktur- mit der Prozeßsicht. 



4. Objektorientierte Realisierung varianter Lösungskonzepte am Beispiel 
NETEX 

Der Forderung nach Exploration vormals unbekannter Problemlösungsmethoden in 
DV-Projekten kann durch den Einsatz zweier Varianten des Projektmanagements ent- 
sprochen werden. 

Vorgehensweisel : Klärung beim Projektstart 

Zu Beginn eines Projekts konunt es in der Phase Grobkonzept zunächst zur Klärung des 
Nukleus z. B. durch die Umsetzung von Methoden der wissenschaftlichen Literatur in 
einen Prototyp. In dieser Voruntersuchung soll geklärt werden, ob eine Methode zur 
Problemlösung geeignet ist. Vorteile dieser Vorgehensweise sind: 
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Ergebnisse sind frühzeitig verfügbar. 

Durch die Konfrontation aller am Projekt Beteiligten mit den Ergebnissen kann 
die Entscheidungsfindung unterstützt werden. 

Wenn es nicht gelingt, eine problemadäquate Lösung zu erarbeiten, ist der jeder- 
zeitige Stop des Projekts möglich. 

Das Lösungskonzept kann unabhängig von technischen Restriktionen gefunden 
werden. 

Das Ergebnis der Voruntersuchung ist ein Sollkonzept. Die Dokumentation dieses 
Vorkonzepts kann im Sinne der Terminplanung in einem Phasenmodell als Mei- 
lenstein betrachtet werden. 

Nachteile bzw. Probleme dieser Vorgehensweise sind: 

Die Lösung kann nicht exakt ermittelt werden, ohne Funktionen des späteren 
Systems verfügbar zu haben. Z. B. kann im Fall des Luftfrachtoptimierungs- 
systems eine Problemlösungsmethode nicht evaluiert werden, ohne umfangreiche 
Implementierungen von Beispieldaten und Prozessen vorzunehmen. Der Aufwand 
für die Implementierung dieser Datenbanken und Funktionen in jedem Prototyp 
unter Mißachtung des Prinzips der Wiederverwendbarkeit kann den Aufwand für 
die Entwicklung der eigentlichen Problemlösung weit übersteigen. 

Die Problemlösungsmethode ist unter Umständen nur im Zeitraum der Grobkon- 
zeption richtig. Bedingt durch lange Projektverläufe bis zur Fertigstellung des 
späteren Systems kann es dazu kommen, daß die Problemlösungsmethode zum 
Zeitpunkt der Einführung des Systems nicht mehr tauglich ist. In der Praxis geht 
dies oftmals mit Organisationsänderungen einher, z. B. werden die Personen 
Auftraggeber und Auftragnehmer und mit ihnen die persönlichen Zieldefinitionen 
ausgetauscht . 

Vorgehensweise 2: Bedarfsklärung zu Beginn des Projekts , Methodenevaluation später 

In dieser Variante wird zu Beginn des Projekts lediglich das Ziel des späteren DV- 
Systems definiert. In der Phase der Grobkonzeption wird anschließend versucht, den 
stabilen Teil des späteren Systems zu erkennen und ihn von der Exploration der Pro- 
blemlösungsvarianten zu trennen. Das Lösungskonzept entsteht im weiteren Projektver- 
lauf durch die parallele Bearbeitung verschiedener Varianten, welche technisch auf der 
Basis stabiler Systemstrukturen ruhen. Im Ergebnis kann dies dazu führen, daß zum 
Ende des Projekts mehrere Varianten parallel implementiert werden und die Auswahl 
einer Lösungsvariante im konkreten Entscheidungsfall dem Anwender überlassen wer- 
den kann. Wichtig bei dieser Vorgehens weise ist jedoch, daß die einzelnen Konzept 
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Varianten in Form von Prototypen realisiert werden, um durch ihren testweisen Einsatz 
vergleichbare Ergebnisse zu erhalten. Die Vorteile dieser Prototyp-Vorgehensweise 
liegen im wesentlichen in [Wolf 90] : 

Erkundung der unklaren Vorstellungen der Anwender 
Risikostudien zu Beginn und im Verlauf der Produktion 
Experimentelle Überprüfung der Spezifikationen 

Demonstration der technisch- wirtschaftlichen Machbarkeit der Funktionen des 
Nukleus 

Gesicherte Erkenntnisse über die "beste" Problemlösung. 

Die Nachteile dieser Vorgehensweise bestehen im wesentlichen in 

dem erhöhtem Projektaufwand für die Erstellung der Prototypen und Verifikation 
alternativer Konzepte, und in 

dem höherem Vertrauen, das der Auftraggeber dem Projektteam entgegenbringen 
muß, weil zu Beginn die Lösungskonzeption fehlt. 

Diese Nachteile können jedoch durch die Tatsache aufgewogen werden, daß die Mehr- 
aufwendungen für die Exploration relativ zum Umfang des gesamten Projekts gering 
sind, und daß im Ergebnis eine höhere Flexibilität der Anwendung sowie eine höhere 
Akzeptanz beim zukünftigen Nutzer zu erwarten sind. Das folgende Beispiel aus dem 
Projekt NETEX soll einen Beleg für die Vorteilhaftigkeit der Vorgehensweise nach 
Vorgehensweise zwei geben. 

Die Zielsetzung im Projekt NETEX ist, ein System zur Unterstützung des Projektleiters 
in einer Multiprojektmanagement-Organisation zu erreichen. Jeder Mitarbeiter ist in der 
Linie disziplinarisch seiner Gruppe, Abteilung, Hauptabteilung oder seinem Bereich 
unterstellt. Die Aufgaben der Unternehmung erfordern es jedoch, daß zu ihrer Bewälti- 
gung Mitarbeiter verschiedener Organisationseinheiten in Projekten zusammengeführt 
werden, für deren Abwicklung ein Projektleiter verantwortlich ist. Die Verwaltung und 
Zurverfügungstellung zentraler Kapazitäten sowie die zielgerechte Planung und Entla- 
stung einzelner Ressourcen ist Ziel einer großrechnerbasierten Software, welche bereits 
eingeführt wurde. Das System NETEX stellt das Front-End-System zu dieser Multipro- 
jektmanagement-Software dar. Es soll dem Projektleiter die Möglichkeit geben, sein 
Projekt mit den Mitteln der Netzplantechnik zu planen und den Projekterfolg ständig zu 
überwachen. Hierzu bietet NETEX unter anderem die Möglichkeit des grafischen Ent- 
wurfs von Netzplänen am Bildschirm an. Diese grafische Unterstützung ist eine der 
EEauptforderungen an das System. 
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In der Literatur wurden bereits einige Algorithmen zur Umsetzung von Graphen in 
Bildschirm- oder Druckausgaben dokumentiert. So wurde bereits 1974 ein allgemein 
gültiger Algorithmus zum Positionieren von Netzplanknoten und Kanten bei MPM- 
Netzplänen entwickelt [Schmitz 74]. Des weiteren ist eine Fülle von Projektmanage- 
ment-Softwaresystemen am Markt verfügbar, denen zum Teil unterschiedliche Algo- 
rithmen zur grafischen Umsetzung der Netzpläne zugrunde liegen. 

Die frühe Festlegung auf eine grafische Repräsentationsform kann dazu fuhren, daß die 
Akzeptanz des Systems beim Anwender leidet. So ist zu beobachten, daß die bisher in 
der Literatur dokumentierten Algorithmen und ihre grafischen Ergebnisse bei den 
Anwendern auf Ablehnung stoßen. Die Befragung der Anwender im Rahmen von 
Expertenbesprechungen hat ergeben, daß die Anforderungen der Anwender meist wenig 
strukturiert und zum Teil widersprüchlich sind. Desweiteren konnte beobachtet werden, 
daß es scheinbar keinen Konsens über die zweckmäßige Gestaltung von grafischen 
Repräsentationen von Netzplänen am Bildschirm gibt. Interessant war zu beobachten, 
daß bereits bei einer Grundgesamtheit von nur 10 Befragten die Ablehnung der bekann- 
ten Zeichenalgorithmen eindeutig vorherrschend war. In der Spezifikation der zusätzli- 
chen Freiheiten bei der Gestaltung grafischer Netzpläne konnte dennoch keine Einigkeit 
erzielt werden. Dies führte zu der Forderung, Varianten der grafischen Darstellung von 
Netzplänen zuzulassen. 

Die Darstellung der Daten- und Prozeßstruktur von Software erfolgt traditionell in 
Form von Entity-Relationship-Diagrammen und Prozeßbäumen [Chen 76] [Constantine 
89]. Die Modellierung der Datenstruktur des vorliegenden Falles zeigt die Komplexität 
des Problems anhand der drei Entities "Vorgänge", "Graphen" und "Darstellungsform". 
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Abbildung 2: Entity-Relationship Entwurf am Beispiel NETEX 
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Die Beziehungen zwischen diesen drei Entities haben jeweils die Kardinalität n:m, d. h. 
jeder Vorgang kann mehreren Graphen zugehören, jeder Graph besteht aus einem oder 
mehreren Vorgängen, jeder Graph kann verschieden dargestellt werden und eine Dar- 
stellungsform kann verschiedene Graphen repräsentieren. Die zugehörigen Funktionen, 
Z.B. zur Ermittlung der Anordnungsbeziehungen sowie zur Errechnung der Koordinaten 
der grafischen Darstellung, werden separat modelliert. Konzentriert man sich auf eine 
einzige Darstellungsform, würde das Datenmodell zwischen den Entities 'Graphen' und 
'Darstellungsform' eine 1:1 Beziehung aufweisen. Es steht zu vermuten, daß dann die 
Attribute des Entity 'Darstellungsform' in das Entity 'Graphen' übernommen würden. 
Dies hätte sowohl aus der Datenstmktursicht wie auch aus der Prozeßsicht den Nachteil, 
daß anschließend eine weitere Darstellungsform nur unter erheblichem Aufwand hin- 
zugefügt werden könnte. Die gleichen Aussagen gelten für die Relation 'Vorgänge '- 
'Graphen'. 
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Abbildung 3: Objektorientierter Entwurf am Beispiel NETEX 

Bei der objektorientierten Modellierung würden die Entities als Klassen abgebildet. Die 
Instanziierung erlaubt, daß es Varianten sowohl der Datenstrukturen wie auch der Pro- 
zesse geben darf. Durch die Verkapselung von Datenstruktur und Funktionen sowie 
deren Vererbung ist gewährleistet, daß alle Objekte einer Klasse über das gleiche Pro- 
tokoll verfügen. Die einzelne Funktion, z.B. Zeichenroutinen für das Fenstersystem, 
kann überschrieben werden. Die m:ri Beziehung der Klassen wird über das Protokoll 
der Objekte definiert. Somit lassen sich sehr effektiv Varianten einfügen. Im Ergebnis 
karm z.B. ein Netzplan gleichzeitig in verschiedenen Fenstern am Bildschirm in unter- 
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schiedlichen Darstellungsfonnen erscheinen. Das Erkennen dieser Möglichkeit im Ent- 
wurfsprozeß resultiert dabei direkt aus der Forderung nach der Abbildung von 
Lösungsvarianten. 



5. Bewertung und Ausblick 

Die vorgeschlagene Vorgehensweise zur softwaretechnischen Abbildung von Lösungs- 
konzeptvarianten mit den Mitteln der objektorientierten Progranunierung soll im Lichte 
der Anforderung des modernen Software Engineering bewertet werden. Hierzu ist es 
erforderlich, die Konzepte des NETEX Prototypen an den allgemeinen Qualitätsmerk- 
malen der Softwareproduktion zu spiegeln. Diese Qualitätsmerkmale der Softwarepro- 
duktion sind unabhängig von Hardware- und Software-Umgebungen definiert. Die 
Qualität einer Software kann an den beiden Kriterien Brauchbarkeit und Wartbarkeit 
bewertet werden[Boehm 86] [Balzert 82]. Unter Brauchbarkeit versteht Boehm den 
Grad des Nutzens, den ein Anwender im Zeitablauf aus dem Produkt ziehen kann, ohne 
daß es zu Produktänderungen kommt. Brauchbar ist eine Software immer dann, wenn 
sie zuverlässig, hinreichend effizient und benutzerfteundlich ist. Die Wartbarkeit eines 
Systems hängt direkt davon ab, ob der Anwender in der Lage ist, das Software System 
zu verstehen, zu testen und zu modifizieren. Hierbei spielt die Transparenz der gegebe- 
nen Softwarelösung die entscheidende Rolle. Neben diesen beiden Nutzenkategorien 
besteht ferner die Forderung nach Portabilität der Software. 

Zuverlässigkeit 

Hinsichtlich der Zuverlässigkeit der relevanten Komponenten von NETEX kann fest- 
gehalten werden, daß durch die Wahl der Objektorientierung als Erstellungsmethodik 
und -technik das System eine hohe Robustheit und Integrität erhält. Diese resultiert aus 
den klaren Schnittstellen der Objekte, wie sie in den Funktionen auf Klassenebene 
definiert sind. So haben unterschiedliche Algorithmen zur Darstellung der Netze am 
Bildschirm exakt die gleichen funktionalen Schnittstellen. Die Software hat so insge- 
samt einen stabileren Charakter, als wenn jedes Modul einzeln kodiert und verwaltet 
würde. Hinsichtlich der Vollständigkeit kann festgehalten werden, daß durch das Ange- 
bot mehrerer Lösungs varianten die Software im Sinne der Anwendung vollständig ist. 
Bei der Vollständigkeit und Genauigkeit der einzelnen Funktionen bleiben die gleichen 
Anforderungen und Restriktionen wie bei einer konventionellen Entwicklung bestehen, 
so daß dieses Merkmal hinsichtlich der Bewertung neutral ist. 

Effizienz 

Die Effizienz der gewählten Lösung hinsichtlich des Erstellungsprozesses ist durch 
objektorientierte Entwicklungsumgebungen determiniert, wie sie z. B. auch von 
SMALLTALK bekannt sind. In dieser Entwicklungsumgebung sind wichtige Parame- 
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ter wie Anzahl der Objekte, Ziigriffswege, Attributlisten, usw. ableitbar. Die Ablaufef- 
fizienz wird durch die Wahl einer Compiler-Sprache gewahrt. Die Verwendung von 
Standardkomponenten wie z. B. dem Fenstersystem, ist ein weiteres Merkmal für eine 
effiziente Realisierung. 

Benutzerfreundlichkeit 

Die Benutzerfreundlichkeit des Systems ist im technischen Sinne determiniert durch die 
Wahl des Fenstersystems sowie des programmtechnischen Umgangs mit ihm. Durch 
das multiple Angebot von grafischen Darstellungsformen ist das System auch im Sinne 
der Anwendung benutzerfreundlich. Die eigentliche Bewertung des Fenstersystems ist 
hier nicht notwendig, da es sich bei einer konventionell erstellten Software um die glei- 
chen Rahmensysteme handeln würde. 

Im Ergebnis bleibt festzuhalten, daß für die Brauchbarkeit der Software auf der Ebene 
der Einzelfunktionen die gleichen Maßstäbe angelegt werden können wie bei einer 
traditionellen Realisierung. Durch das konsequente Anwenden des Prinzips der Varian- 
tenvielfalt erhält der Nutzer standardmäßig mehrere Problemlösungsmethoden zur 
Auswahl angeboten, was im Ergebnis die Benutzerfreundlichkeit des Systems aus seiner 
Sicht steigert. Jedoch ist für die Forderung nach Benutzerfreundlichkeit die objektori- 
entierte Realisierung der Software nicht entscheidend. Lediglich das Argument der 
schnelleren Systemerstellung durch Prototyping unter Verwendung von objektorientier- 
ten Programmierumgebungen ist zu unterstreichen. Die allgemeine empirische Überprü- 
fung der Rationalisierung der Sofiwareproduktion durch den Einsatz objektorientierter 
Techniken steht noch aus. 

Die zweite große Forderung an Software Systeme ist, daß in der Zukunft die Aufwen- 
dungen für Wartung und Pflege gering sein sollen. Es wird dabei davon ausgegangen, 
daß der Anteil der Aufwendungen für Wartung und Pflege and den Gesamtaufwendun- 
gen über den Lebenszyklus der Software einen sehr großen Anteil hat. 

Testbarkeit 

Für objektorientierte Systeme, und hier speziell auch NETEX, gilt, daß es derzeit keine 
allgemein anerkannten Testverfahren und Testwerkzeuge für das Gesamtsystem gibt. 

Es gelten jedoch für die Tests der Einzelfunktionen von NETEX die gleichen Aussagen, 
wie bei dem Test der Einzelfunktionen einer traditionell erstellten Software. Durch die 
kompakte und modulartige Architektur objektorientierter Systeme und die klar definier- 
ten Schnittstellen zwischen den Objekten erscheint der Modultest gegenüber einem 
Test traditioneller Software vereinfacht. Insbesondere der Test der Objektschnittstellen 
ist stark vereinfacht, da alle Instanzen einer Klasse über die gleichen Schnittstellen- 
funktionen verfügen. 
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Verständlichkeit 

Die Verständlichkeit des Codes einer Software resultiert zum einen aus den Entwurfs- 
dokumenten und zum anderen aus dem dokumentierten Quellcode. In der objektorien- 
tierten Programmierung sind die Objekte selbst die Struktur, d. h. die Anwendungs- 
struktur wird durch die Wahl der Objekte und ihrer Attribute sowie des Vererbungsnet- 
zes determiniert. Dies stellt eine gänzlich neue Programmstrukturierung dar, die auf 
keinen Fall mit der von Programmmen einer sequentiellen Programmiersprache (z. B. 
Cobol) verglichen werden kann. Da zum Verständnis des Progranuns sowohl "White- 
box' wie 31ack-box' Betrachtungen auf Objektebene angestellt werden können, ist 
unter Verwendung einer objektorientierten Entwicklungsumgebung mit Browsern, 
Editoren usw. die Verständlichkeit des Codes gut gewährleistet. 

Änderbarkeit 

Die Änderbarkeit einer Software resultiert direkt aus dem Grad ihrer Strukturierung. 
Durch die einerseits hohe und andererseits einfache Form der Strukturierung durch 
Objekte ist ein hoher Grad der Änderungsflexibilität zu erwarten. Dies war gerade das 
Ziel der Entwicklung von NETEX im objektorientierten Modell. So ist z. B. das 
Ändern oder Zufiigen eines weiteren Zeichenalgorithmus für Netze durch einfache 
Instanziierung und anschließender Modifikation der verkapselten Funktionen möglich. 
Das Einbringen eines neuen Objekts in den Programmablauf erfolgt über die gleichen 
Schnittstellen, wie sie auch allen anderen Instanzen dieser Klasse zur Verfügung steht. 
Insbesondere durch die klare Definition der Schnittstelle ist eine hohe Änderungsfle- 
xibilität gegeben. 

Im Ergebnis sprechen aus Anwendungs- und Software-Sicht gerade die Überlegungen 
zur Wartbarkeit und zukünftigen Weiterentwicklungsfahigkeit der Software für die 
Realisierung mit objektorientierten Techniken in den Fällen, in denen eine Exploration 
geboten ist. In Zusammenfassung der obigen Ausführung kann festgehalten werden, 
daß durch die objektorientierte Vorgehensweise sowohl der Anwender durch das Ange- 
bot von Varianten der Problemlösung, als auch die Entwickler durch die Wartbarkeit 
der Software profitieren. Es wird deshalb die gewählte Vorgehensweise für alle solche 
Projekte empfohlen, in denen entweder eine eindeutige Auswahl der Problemlösungs- 
methode zu Beginn der Entwicklung nicht möglich ist, oder bei denen durch die Art der 
Anwendung eine hohe Änderungsrate vermutet werden kann. Für die Zukunft steht 
deshalb zu erwarten, daß Verfahren und Methoden verschiedener Wissenschaftsgebiete 
in Form von Basisklassen objektorientierter Systeme standardmäßig auf einem Compu- 
ter verfügbar sein werden. Dies gilt jedoch aus heutiger Sicht nüt der Einschränkung, 
daß die überwiegende Mehrzahl objektorientierter Sprachen und Entwicklungsumge- 
bungen derzeit nur für Workstation und PC-Umgebungen angeboten werden. Es bleibt 
abzuwarten, ob die Unterstützung der Variantenvorgehens weise in der Zukunft auf allen 
Hardwareplattformen möglich sein wird. 
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Zusammenfassung 

ln der Kl wurden seit Beginn der 70er Jahre Arbeiten zum Thema Constraints 
(wörtlich etwa "Einschränkung", "Nebenbedingung") veröffentlicht. Das Interesse an 
Constraints kam anfangs aus der Bildverarbeitung, war dann längere Zeit vorwiegend 
theoretischer Natur und ist seit einigen Jahren auch wieder stärker von praktischen 
Anwendungen geprägt. Überschneidungen bestehen zum OR sowohl hinsichtlich der 
Fragestellungen, die mit Constraint-Netzen angegangen werden, als auch in Bezug auf 
die Lösungstechniken, die zum Einsatz kommen. Der Aufsatz versucht aufzuzeigen, wie 
aus der Praxis der Software-Entwicklung ein Zugang zu diesem Thema gefunden wurde, 
ohne auf die theoretischen Hintergründe näher einzugehen. 
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1. Einleitung 

Im letzten Jahrzehnt ist im Bereich der Künstlichen Intelligenz (Kl) eine 
umfangreiche Literatur zum Thema Constraints entstanden. Dabei werden 
Constraints teilweise sehr formal betrachtet mit dem Schwerpunkt, effiziente 
Algorithmen zu finden und deren Komplexität zu analysieren. 

Andererseits gibt es inzwischen auch zahlreiche Arbeiten zur praktischen 
Anwendung von Constraints. speziell in den Bereichen interaktive 
Computergrafik, CAD und Konfiguration mit Wissensbasierten Systemen. 

In der (englisch-sprachigen) OR-üteratur wird dagegen meines Wissens der 
Begriff Constraint nur in der Bedeutung "(einschränkende) Nebenbedingung" 
gebraucht, also etwa "Constrained optimization". 

Die Darstellung und Verarbeitung von Wissen mit Constraint-Netzen ist aber ein 
allgemeines und vielseitig verwendbares Paradigma, das nicht ausschließlich der 
Kl oder dem OR zugeordnet werden kann. 

Bereits 1974 schrieb Montanari, einer der "Urväter" derConstraint-Literatur in 
seinem Aufsatz Networks of Constraints: Fundamental Properties and 
Applications to Picture Processing:" ... many practical design Problems consist of 
finding any solution which satisfies all topological and geometrical restrictions. 
Even when an optimization problem must be stated, the chosen constraint 
representation is essential in determining the nature of the mathematical 
Problem involved and itsdifficulty" (S. 95f). 

Für den Praktiker ist Montanaris Arbeit durch die formal-mathematische 
Behandlung des Themas nur schwer zugänglich. Das gilt auch für einen großen 
Teil der neueren Kl-Literatur zu diesem Thema. Die Anwendung auf Probleme 
aus der Praxis drängt sich nicht unbedingt auf. Deshalb ist es vielleicht interessant 
zu sehen, wie wir von einer konkreten Problemstellung auf den Constraint- 
Formalismus stießen und im Laufe weiterer Projekte immer mehr die vielseitigen 
Anwendungsmöglichkeiten entdeckten. 

Beim Projekt CAD/X (Braun 1989) ging es darum, ein Lösungskonzept zu 
erarbeiten, wie Konstrukteure bei der Auswahl von Norm- und Wiederholteilen 
durch ein Programm unterstützt werden könnten. Neben einer konzeptionellen 
Studie sollte ein Software-Modell entstehen, um die Machbarkeit an einem 
relativ einfachen Beispiel zu demonstrieren. Man entschied sich dafür, die 
"Auswahl von Wälzlagern" zu verwenden. Die Aufgabe des Konstrukteurs 
besteht dabei darin, z.B. bei der Konstruktion eines Elektromotors Wälzlager aus 
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einem vorhandenen Angebot so auszuwählen, daß sie in die Konstruktion 
passen. Neben den geometrischen Abmessungen können dabei auch Belast- 
barkeit, Gewicht, Preis etc. eine Rolle spielen. Das dafür erforderliche Wissen ist 
nicht zu komplex, kann auch vom Nicht-Fachmann verstanden werden und liegt 
übersichtlich in Form von Katalogen der Hersteller vor. In diesen Katalogen 
fanden wir Tabellen von Wälzlagern, Berechnungsformeln, Nomogramme und 
Regeln, wann welche Art von Lager in Betracht zu ziehen ist. 

Eine reine Datenbankanwendung kam nicht in Frage, weil die Zusammenhänge 
zwischen Suchen in Tabellen, Beachtung von Regeln und Durchführung von Be- 
rechnungsschritten zu komplex waren. Es gibt auch keine feste Reihenfolge, in 
der diese Schritte vom Konstrukteur durchgeführt werden. Deshalb wurde ver- 
sucht, eine Lösung mit Hilfe von Prinzipien der Wissensverarbeitung zu finden. 



2. Wissensverarbeitung 

Die Lösung von Problemen erfordert Wissen. Um problemrelevantes Wissen 
verarbeiten zu können, muß es explizit dargestellt werden. Dazu braucht man 
einen Formalismus bzw. eine Sprache. Bekanntlich eignet sich natürliche Sprache 
zwar für eine erste Problembeschreibung bis hin zur ‘‘Einkreisung* des Problems. 
Zur konkreten Ausarbeitung einer Lösung mit Hilfe von Computern bedarf es 
aber wegen der Mehrdeutigkeit natürlicher Sprache künstlicher Sprachen mit 
genau definierter Semantik. Doch welche Arten von Wissen sind nötig, um ein 
Problem zu lösen? 



2. 1 Wissen über Problem-Domäne 

Offensichtlich sollteein * Problemlöser* (Mensch oder Maschine) über Wissen 
bezüglich des jeweiligen Fachgebietes verfügen. Um beim Beispiel der Auswahl 
von Wälzlagern zu bleiben: Der Konstrukteur weiß, daß es bestimmte Klassen 
von Wälzlagern gibt (Kugellager, Rollenlager) und daß diese weiter unterteilt 
werden (Kugellager in Rillenkugellager ..., Rollenlager in Pendelrollenlager ...). 
Er kennt also relevante Objekte der Problem-Domäne, darüber hinaus aber auch 
relevante Eigenschaften oder Attribute dieser Objekte, z.B. die geometrischen 
Abmessungen, Belastbarkeit usw. 

Schließlich weiß er, daß nicht nur Objekte in Beziehung zueinander stehen 
(Klassenbildung), sondern auch manche Objekt-Attribute. 
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Attribut-Beziehungen werden in der Praxis häufig durch Formeln, Tabellen und 
Regeln ausgedrückt ( Lebensdauer = (C7P)^ * 10V60n usw.). Wie auch immer die 
Ausdrucksform, es handelt sich um Constraints im Sinne der "einschränkenden 
Nebenbedingungen". 

In einer konkreten konstruktiven Situation kommt nun noch das reine 
Faktenwissen über bestimmte Werte von Attributen hinzu. So könnte etwa 
die maximale Drehzahl 2000 min ' sein, die Breite des Lagers 20 mm, die 
Schmierungsart "Fett" usw. 



2.2 Wissen über Lösungsprinzipien für Problemklassen 

So weit existiert also Wissen über eine Domäne. Ein Problem entsteht erst, wenn 
Fragen über diese Domäne gestellt werden. Dabei bestimmt die Art der Frage in 
der Regel die Problemkiasse. Möchte der Konstrukteur z.B. wissen, ob es Teile mit 
einem Außendurchmesser von X und einer Breite von Y gibt, handelt es sich um 
ein Suchproblem. Ein sinnvoller Suchalgorithmus wird sich daran orientieren, wie 
die Teile (z.B. in einer Datenbank) abgelegt sind. Hier kommt Wissen über 
Suchmethoden und über die Organisation der zu durchsuchenden Daten ins 
Spiel. 

Lautet die Frage dagegen, wie hoch die Lebensdauer eines bestimmten Lagers 
ist, wenn Drehzahl und Belastung gegeben sind, so muß die oben zitierte Formel 
"ausgerechnet" werden. Dafür kommt arithmetisches Wissen zum Einsatz bzw., 
wenn nach einer Größe aufgelöst werden muß. Wissen über algebraische 
Umformungen. 

Ohne daß darüber in der täglichen Praxis besonders nachgedacht 
wird, verwendet man also häufig die (problemneutrale) Sprache der Algebra, um 
einen Teil des Domänenwissens zu formulieren. Somit wird es nötig, neben der 
Semantik der eigentlichen Problembeschreibungssprache auch die 
(wohldefinierte) Semantik weiterer (formaler) Sprachen wie der Algebra zu 
kennen, um das zur Problemlösung nötige Wissen verarbeiten zu können. 

D.h. es nützt wenig, wenn man bei der Bearbeitung einer Fragestellung die 
Lagerbelastung "P" benötigt und auf die Formel 

Lebensdauer = (C/P)3* i06/60n 



stößt, aber nicht weiß, wie diese nach "P" aufzulösen ist. 
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Abstrahiert man obiges Beispiel der Auswahl von Wälzlagern, so gelangt man zu 

einer Problemklasse "Auswahl (von geeigneten Objekten)". Im Rahmen des 

Projektes CAD/X hatten wir dafür folgendes Lösungsmuster erarbeitet: 

Schritt 1 : Strukturierung der vorhandenen Objekte in eine Hierarchie von 

Klassen (Generalisierung bzw. Spezialisierung). 

Schritt 2: Festlegung der Attribute der Objekte und der Situationsparameter. 

Ein Situationsparameter ist z.B. die im Betrieb auftretende 
Belastung eines Lagers. Dagegen ist die maximale Belastbarkeit 
des Lagers ein Objektattribut. 

Schritt 3: Aufstellung von Regeln, die in Abhängigkeit von Situations- 

parameterwerten angeben, welche Objektklassen in Frage 
kommen. Können solche Regeln gefunden werden, führt das u.U. 
bereits zu einer erheblichen Einschränkung des Suchraumes. 

Schritt 4: Aufstellung von Zusammenhängen (Constraints) zwischen 

Objektattributen und Situationsparametern. Dabei gibt es folgende 
Möglichkeiten: 



Situationsparameter Objektattribute 




Zusammenhänge innerhalb Zusammenhänge innerhalb 

der Situationsparameter der Objektattribute 



Zusammenhänge zwischen 
Situationsparametern und Objektattributen 
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Wir betrachteten das Auswahlproblem als Suchproblem, bei dem es darum geht, 
Objekte zu finden, die den Klassen gemäß Schritt 3 angehören und deren 
Attribute den Bedingungen nach Schritt 4 genügen. 

Als sich herausstellte, daß in aller Regel die Menge von so gefundenen Objekten 
nach bestimmten Attributen sortiert wird, um ein "optimales" Objekt zu finden 
(z.B. höchste Lebensdauer, niedrigster Preis, niedrigstes Gewicht, kürzeste 
Lieferzeit, ...), zeigte sich die Ähnlichkeit der Problemstellung zu Optimierungs- 
problemen aus dem OR. 

Z.B. könnte ein Auswahlproblem folgendermaßen formuliert werden (stark 
vereinfacht): Für eine gegebene Konstruktion soll ein Lager ausgewählt werden. 
Vorgegeben sind Außendurchmesser, Breite und die Belastung des Lagers. Der 
Preis soll auf keinen Fall höher als x DM sein und die Lebensdauer (Lioh) soll 
möglichst hoch sein. 



Das ergibt folgendes Designproblem: 



Designvektor: X = 



C 

P 

n 

Preis 

Au ßend u rch messer 
Breite 



Erläuterung; C = Tragzahl, P = Äquivalente Lagerbelastung, 
n = Drehzahl 

Maximiere f (C, P, n) = Lioh = (C/P)3 • 106/60 » n 

unter den Nebenbedingungen: Preist x 

Außendurchmesser = a 
Breite = b 
P = p 

Allerdings ist unmittelbar klar, daß klassische Optimierungsverfahren nicht 
anwendbar sind, weil die Tragzahl C keine kontinuierliche Variable ist (es gibt 
nur endlich viele Objekte mit dem Attribut C). 
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Ein weiteres Problem mit OR-Ansätzen schien uns zu sein, daß Auswahlprobleme, 
wie wir sie kennengelernt haben, immer sehr interaktiv abgewickelt werden, 
d.h. das zu maximierende Attribut und die Menge der Nebenbedingungen 
ändern sich von Fragestellung zu Fragestellung. Der Benutzer eines 
Auswahlsystems möchte natürlich nicht jedesmal das Problem vollständig neu 
formulieren müssen, sondern auf inkrementeile Weise "What-if-Szenarios" 
durchspielen. 

An dieser Stelle stießen wir bei unserer Suche nach einem geeigneten Basis- 
Formalismus für solche Auswahlprobleme auch auf das Thema Constraints. 



3. Constraint Satisfaction Problems (CSP) 

3.1 Formale Definition 

Ein CSP (manchmal auch "Consistent Labeling Problem") wird in der Kl-Literatur 
meist folgendermaßen definiert (Vgl. etwa Güsgen 1985, Meseguer 1989 oder zu 
anderen Formulierungen desselben Problems Mackworth 1977, Freuder 1978): 

V n-elementige Menge, V = {xi,... ,Xn}, Di,... ,Dn Mengen. 

Die Elemente xi,... ,Xn werden Variablen genannt. 

Die Menge D( wird aufaefaßtals der Wertebereich der Variablen x^ .1 ^ i ^ n. 
Ein Constraint auf einer Teilmenge { Xj,, ... , Xj^ } der Variablenmenge V ist eine 
Relation R C Dj, x ... x Dj^. 

Eine Belegung der Variablen f : V -» U , * j * „ D. erfüllt den Constraint, wenn es 
ein (n,, ... , ) € R gibt mit = f(xj|j ) für 1 ^ k ^ m . 

Ein Constraint-Netz auf V ist eine Menge C von Constraints auf Teilmengen 
von V. 

Jedes Constraint-Netz C definiert ein Constraint Satisfaction Problem (CSP): 

Gibt es eine Belegung der Variablen f : V -» U , ^ . s „ D^ , die alle Constraints 
aus Cerfüllt? 

Jede Belegung der Variablen f : V -» U , ^ j ^ „ Di , die alle Constraints aus C 
erfüllt, heißt eine Lösung des durch C definierten CSP. 



Ein Constraint-Metz kann als Graph dargestellt werden, dessen Knoten die 
Variablen entsprechen. Zwei Knoten werden durch eine mit R bezeichnete Kante 
verbunden, wenn die beiden Variablen Elemente der Teilmenge von V sind, auf 
der der Constraint definiert ist. 
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Beispiel: V = {xi,X 2 , X 3 , X 4 , xs } 

Dl = {1,2,3} = D2 = D3 
D 4 = (4, 5,6,7} = Ds 
Constraint Ri c Di x D3 x D5 
Constraint R 2 c D 2 x D 4 

XI X2 




Ri = {(1,1.5), (1,3,7) } 

R 2 = {(2,6),(3,4),(1,5)} 



Erweitert man dieses (triviale) Constraint-Netz z.B. um einen Constraint 
R 3 c Dl X D 2 X D 3 , so entsteht ein zusammenhängender Graph, also das, was man sich 
umgangssprachlich unter einem Netz vorstellt. 

R3 

XI X2 

Ri 

X3 




In der theoretischen Kl-Literatur zum Thema CSP werden nun Algorithmen zur 
konsistenten Belegung der Variablen mit Werten unter der wesentlichen 
Einschränkung untersucht, daß die Wertebereiche der Variablen endlich sind 
(für einen knappen Überblick neueren Datums über diese Literaturrichtung 
s. Meseguer 1989). 



3.2 Extensionale und intensionale Constraints 

Nun läßt bereits das Beispiel CAD/X vermuten, daß in praktischen Anwendungen 
meistens sowohl diskrete, endliche (z.B. das Objekt-Attribut Tragzahl C), als auch 
kontinuierliche, unendliche Wertebereiche (z.B. Lebensdauer) von Variablen 
auftauchen. Ein Software-Werkzeug zur Verarbeitung von Constraints sollte 
beiden Fällen gerecht werden. 
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Zum anderen scheinen sprachunabhängige Ansätze, Constraint-Netze 
durch Standard-Graphenalgorithmen aufzubereiten, erfolgversprechend 
(z.B. Serrano 1987). Zudem sind durch die explizite Repräsentation als Graph 
nach der Berechnung einer Lösung Erklärungen für den Benutzer ableitbar , 
wie das Ergebnis zustandekam (vgl. dazu auch Steele 1980). 

Ein weiterer Vorteil seines Ansatzes ist, daß sich durch eine Analyse des 
Constraint-Graphen mit Zuordnungs-Algorithmen feststellen läßt, ob ein 
"overconstrained / underconstrained problem" vorliegt. 

Die Frage, ob Constraints nun eher ein Kl- oder OR-Thema sind, ist letzten Endes 
rhetorischer Natur. Orientiert man sich an der Verwendung des Begriffes in 
Publikationen, so wird man vorwiegend in der Kl-Literatur fündig. Aber selbst 
damit ist der Rahmen zu eng gesteckt. Auch in der Welt der Datenbanken ist der 
Begriff geläufig. Wertet man dagegen als entscheidendes Kriterium die Frage, 
welche Lösungstechniken verwendet vverden, dann stellt man fest, daß die 
Informatiker dabei sind zu entdecken, daß das OR z.T. bereits effiziente 
Methoden für spezielle Constraint-Probleme entwickelt hat. "Informatische" 
und OR-Ansätze durchdringen sich also gegenseitig. Schließlich scheint durch das 
Denken in Constraints auch bei den bearbeiteten Problemklassen eine 
Annäherung zwischen Kl und OR stattzufinden. 

Ob die in Entwicklung befindlichen Constraint-Systeme und -Sprachen auch bei 
sehr großen Problemen von der Effizienz her gegen spezialisierte OR-Verfahren 
bestehen können, bleibt abzuwarten. 
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4. Beispiele 

Anhand von zwei weiteren Beispielen soll demonstriert werden, wie Constraints 
zur praktischen Problemlösung eingesetzt werden können. 



4.1 Blisterauslegung 

Im ersten Fall geht es um die Auslegung von sogenannten Blistern. Das sind 
Verpackungen von Tabletten, Dragees, Kapseln usw. 



I — II — I r — II — I 



o 


o 


o 


o 


o 


o 


o 


o 


o 


o 


■ o 


o 



Ein Blister läßt sich vereinfacht durch folgende Variablen beschreiben: 

Länge (L), Breite (B), Anzahl der Produkte in x-Richtung (Nx), Anzahl der 
Produkte in y-Richtung (Ny), Abmessungen der Produkte in x- und y-Richtung 
(Px. Py). Produktabstand (D),vorhandene Perforation (keine, längs, quer, kreuz), 
vorhandenes Coding, d.h. Prägungen im Randbereich (keines, links, rechts, oben, 
...)... usw. 

Das Problem besteht nun darin, daß die Kunden (Pharmaindustrie) eines 
Herstellers von Blistern von Fall zu Fall völlig verschiedene Vorgaben und 
Randbedingungen haben. Zum einen ist denkbar, daß ein Kunde die Form seiner 
Produkte angibt (Dragee, Kapsel ...), deren Abmessungen und die Anzahl pro 
Blister. 

Genausogut kann es aber sein, daß für die Anzahl und Abmessungen der 
Produkte nur Grenzen angegeben werden, gleichzeitig aber von der 
Verpackungsmaschine eine Mindestleistung verlangt wird, die wiederum von der 
Größe der Blister abhängt. 

Schließlich ist es möglich, daß der Auftraggeber z.B. aus Marketinggründen 
unbedingt bestimmte Blisterabmessungen einhalten will und lieber bezüglich 
der auf dem Blister unterzubringenden Produkte mit sich reden läßt. 
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Wenn man weiß, daß außerdem z.B. das Material der Blisterfolie Einfluß auf die 
Mindestproduktabstände hat. kann man sich vorstellen, daß das Problem 
weniger trivial ist. als es auf den ersten Blick erscheint. Die endgültige Klärung 
der Blisterauslegung ist das Ergebnis eines längeren Dialoges zwischen 
Auftraggeber und Auftragnehmer, bei dem frühere Festlegungen u.U. wieder 
zurückgenommen werden. Die Auswirkung von inkrementeilen Änderungen 
sollte also möglichst sofort sichtbar werden. 

Das Problem Blisterauslegung ließe sich mit Hilfe von Constraints etwa 
folgendermaßen beschreiben (vereinfachter Auszug): 

(1) B = (Ny-1)*D + 2»Randy + Ny*Py 

(2) L = (Nx-1)*D + 2*Randx + Nx»Px 

(3) Durchsatz = Folienqeschwindiqkeit * Rollenbreite 

L B 

(4) Produktart € { Kapsel, Dragee, Tablette } 

(5) Produktart i { Dragee, Tablette } -» Px = Py 

Eine Constraint-Sprache, in der obige Ausdrücke die Semantik haben, die man 
sich intuitiv beim Lesen vorstellt, würde es sogar dem Anwender (hier dem 
Hersteller der Verpackungsmaschinen) ermöglichen, sein Problem zu 
formulieren. Diese Ausdrücke wären dann nämlich gleichzeitig ein Programm, 
das unmittelbar vom Computer ausgeführt werden kann. 

Zu dieser Semantik noch einige Anmerkungen: Jede klassische Computer- 
sprache hat Ausdrücke wie B = (Ny - 1) * .... die sich syntaktisch nicht von der 
Constraint-Formulierung unterscheiden. Die Bedeutung ist jedoch: 'Werte den 
rechts des Gleichheitszeichens stehenden Ausdruck nach den Regeln der 
Arithmetik aus und weise das Ergebnis der Speicherzelle mit dem Namen 'B' zu'. 
Die "Formel" kann also nur in eine Richtung verwendet werden. Soll z.B. nach 
Ny aufgelöst werden, so muß der Programmierer das bereits vor der 
Programmausführung von Hand tun. Außerdem muß er durch explizite 
Fallunterscheidungen feststellen, welche Variablen bekannt sind und welche 
ausgerechnet werden soll. 

Die Semantik des gleichen Ausdrucks in einer Constraint-Sprache ist dagegen : 
"hier ist eine Formel über den Zusammenhang der Variablen B, Ny ... Wenn 
genügend Werte bekannt sind, errechne die übrigen." Besonders interessant 
(und entsprechend schwierig zu realisieren) wird diese Semantik, wenn, wie im 
Beispiel, zahlreiche Constraints gleichzeitig gelten (eben ein Constraint-Netz). 
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Hier wird auch wieder ein Berührungspunkt mit OR deutlich: solche Constraint- 
Programme lassen sich auch als Gleichungssysteme interpretieren. Dafür könnte 
man bekannte numerische Methoden einsetzen, wie etwa Newton-Raphson- 
Iteration oder ähnliche Algorithmen. Mit Methoden der Symbolverarbeitung, 
wie sie aus der Kl bekannt sind, können Lösungen auch durch Elimination und 
Substitution gefunden werden, je nach Anzahl der Variablen und Gleichungen 
auch als parametrisierte Lösung (vgl. Sterling und Shapiro 1988, Silver 1986). 

Wie das Beispiel zeigt, müssen aber auch extensionale Constraints, die zudem 
häufig nicht-numerisch sind, verarbeitet werden können. 

Wichtig und leider problematisch ist Constraint Nr. 5. Leier (Leier 1988, S. 32) hat 
diese Regeln aksecond-order constraints bezeichnet. Constraint Nr. 5 bedeutet 
umgangssprachlich " wenn das Produkt Dragee oder Tablette ist, dann sind die 
Produktabmessungen in X- und Y-Richtung gleich (weil das Produkt dann 
kreisrund ist)". Wenn die Regel wie hier als Implikation formuliert ist, kann 
umgekehrt aus der Tatsache, daß die X- und Y-Abmessungen gleich sind, nicht 
geschlossen werden, daß es sich um Dragee oder Tablette handelt. Möchte man 
das ausdrücken, müßte man die Äquivalenz (^) verwenden. Auf jeden Fall 
bedeutet die Einführung von second-order constraints, daß eine praktisch 
brauchbare Constraint-Sprache auch die Bool'sche Verknüpfung von "first-order 
constraints" zulassen sollte. 

Eine Bool'sche Verknüpfung liegt übrigens auch bei simultanen Gleichungs- 
systemen vor. Man macht sie sich nur selten bewußt und schreibt sie auch nicht 
explizit. Wenn n Gleichungen gleichzeitig erfüllt sein sollen, heißt das ja, daß 
gelten soll: Gi A G2 a ... A Gn (s.a. Mackworth 1977). 

4.2 Konfiguration von Produktvarianten 

Im zweiten Beispiel geht es um die Konfiguration von Meßgeräten nach 
Kundenangaben. Diese Aufgabe erfordert ähnlich wie das Auswahlproblem 
zunächst eine Strukturierung des Wissens über die vorhandenen Komponenten. 
Das gesamte Produktspektrum des Herstellers kann in eine überschaubare 
Menge von Erzeugnisklassen gegliedert werden. Von jeder dieser Klassen ist 
bekannt, aus welchen Baugruppen sie grundsätzlich besteht, woraus die 
Baugruppen bestehen usw. 

Jede Erzeugnisklasse wird also durch eine Stückliste beschrieben, deren 
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Positionen aber nicht eindeutige Teile sein müssen, sondern die selbst wieder 
Klassen sein können. Deshalb müssen beim Durchlaufen einer Stückliste im 
Kundenauftragsfall Entscheidungen getroffen werden, welche Komponenten 
tatsächlich in das Enderzeugnis eingehen und welche nicht. 

Zum Zweck der Demonstration des Lösungsansatzes soll folgender Auszug aus 
der Stückliste eines Drehspulmeßgerätes genügen (Die Dimensionen sind der 
Einfachheit halber weggelassen). 
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Der Meßwerkstrom fließt durch eine Drahtwicklung auf einem Metallrähmchen, 
das im Feld eines Dauermagneten drehbar gelagert ist. Auf dem Rähmchen ist 
ein Zeiger angebracht. Durch die Abstoßung von elektromagnetischem und 
magnetischem Feld dreht sich das Rähmchen und der Zeiger zeigt auf einer 
entsprechend geeichten Skala den Meßwert an. Im Bild der Stückliste stehen 
beispielhaft einige Formeln, die Zusammenhänge zwischen Klassen von 
Komponenten beschreiben. Doch auch hier gibt es wieder Constraints, die sich 
nur durch Aufzählung von Werten angeben lassen. Der Grund ist wie schon im 
ersten Beispiel, daß die Constraint-Variablen Objekt-Attribute sind und es aus 
Fertigungsgründen nur eine endliche Reihe von Magneten, Widerständen, 
Wicklungen usw. gibt. 

Neben der Möglichkeit, konkrete Teile aus einer Klasse auszuwählen (im Kl- 
Jargon "Instanzen”), gilt es aber z.T. auch zu entscheiden, welche von mehreren 
Unterklassen einer Klasse die Anforderungen erfüllen könnte. Aus der Stückliste 
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geht hervor (nicht im Bild), daß in jedes Gerät eine Schaltung eingeht. Dafür gibt 
es verschiedene Typen (Unterklassen) von Schaltungen, von denen jede einen 
anderen Constraint in das Konfigurationsproblem einbringt. Das Constraint-Netz 
verändert sich mit anderen Worten dynamisch während des Konfigurations- 
prozesses. 

Beim Durchsuchen der Stückliste kann es sein, daß Constraints angetroffen 
werden, die noch nicht auswertbar sind, weil Variablenwerte unbekannt sind. In 
diesem Fall wird der Constraint in eine Warteschlange eingereiht. 

Constraints, die als Gleichungen formuliert sind, dienen in diesem Beispiel zur 
Berechnung von Werten; Constraints, die Ungleichungen sind, werden als 
Prädikate betrachtet, d.h. sie ergeben bei Auswertung entweder "wahr” oder 
"falsch". Im letzteren Fall wird zurückverfolgt, welcher Gleichungs-Constraint für 
die Verletzung verantwortlich ist. Die Variablen, die dieser Constraint enthält, 
kann man sich als Freiheitsgrade vorstellen. Diejenigen Variablenwerte, die Teile- 
Attributesind, wiez.B. die Magnetkonstante "K" oder die Windungszahl "W", 
können verändert werden, indem ein alternatives Teil ausgewählt wird 
("dependency-directed-backtracking"). Auf diese Weise wird schließlich 
entweder eine konsistente Konfiguration gefunden, oder die eingegebenen 
Anforderungen können durch kein Erzeugnis erfüllt werden. 

Die Zuordnung von Constraints zu Komponentenklassen und ihre dynamische 
Aktivierung während des Suchprozesses ließe sich natürlich wie im vorherigen 
Beispiel syntaktisch als Äquivalenz ("Regel") ausdrücken, etwa: 

(Schaltung = 005) ** (Ri + Rz = ... ) 

Der Denkweise bei dieser Art von Anwendung kommt es aber eher entgegen, 
Constraints, die nicht global gelten, den Komponenten zuzuordnen (wie 
Attribute), von denen sie verursacht werden. Syntaktisch kann das z.B. so 
aussehen: 



Schaltung 005: 

Attribut 1 = ..., 
Attribut 2 = ..., 
Ri + R2 = ..., 
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Kurz zusammengefaßt besteht das Lösungsprinzip ähnlich wie im ersten Beispiel 
aus einer Kombination von "Wissensstruürtur/erung" (Klassenhierarchie, 
Stücklistenhierarchie), Suc/te auf diesen Strukturen und Steuerung der Suche 
durch Constraints. 



5. Entwicklungslinien und Ausblick 

Der Begriff "Constraints" entwickelt sich in der Kl in den letzten Jahren 
zu einem Schlagwort, ähnlich wie das auch mit der sogenannten 
"Objektorientierten Programmierung" der Fall war. Die Definition eines 
Constraint-Netzes als Menge von Relationen auf einer Menge von Variablen ist 
so allgemein, daß man auch logisch-relationale Programmiersprachen wie 
PROLOG, relationale Datenbanken ("integrity constraints"!), simultane 
Gleichungssysteme, Spreadsheets und vieles mehr in das Constraint-Paradigma 
einordnen könnte. Wenn solche Gedankengänge auch interessante Perspektiven 
eröffnen mögen, so sind sie doch zu allgemein, als daß sie zu praktisch oder 
theoretisch unmittelbar verwertbaren Erkenntnissen führten. 

Erfolge stellten sich sowohl in der Kl als auch im OR gerade dann ein, wenn 
man sich auf spezielle Probleme beschränkte. Gerade im OR wird das sehr 
deutlich etwa bei Optimierungsproblemen, die in zahlreiche Problemklassen 
unterteilt werden können, für welche dann spezielle Methoden existieren. Diese 
könnten als Lösungsbausteine in Constraint-Systemen der Kl Anwendung finden 
(z.T. schon erfolgt). 

Auf der Seite der Kl möchte ich die Arbeiten zum Thema Constraints in drei grobe 
Kategorien einteilen. Zum einen gibt es recht umfangreiche Literatur zu der 
Klasse von Constraintproblemen, in denen nur endliche, diskrete Wertebereiche 
zugelassen sind. Wie oben erwähnt, hatte diese Einschränkung theoretische 
Gründe, doch sind effiziente Algorithmen dafür durchaus von praktischem 
Interesse, wenn man an Probleme der kombinatorischen Optimierung denkt 
(Scheduling, Resource Allocation und viele andere). Hier könnte vielleicht die OR- 
Seite von Kl-Arbeiten Anregungen aufnehmen. 

Eine zweite Richtung wird durch tatsächlich implementierte experimentelle 
Software-Systeme repräsentiert, für die stellvertretend Sketchpad (Sutherland 
63) und ThingLab (Borning 81) genannt werden sollen. Dabei handelt es sich um 




257 



weniger formalisierte Ansätze, die z.T. über mehrere Methoden verfügen, um 
ein gegebenes Constraint-Netz zu berechnen. Das "Arbeitspferd" solcher 
Programme ist meistens eine Form von local propagation (s. z.B. Leier 1988, 

S. 16ff). Local-propagation-Algorithmen sind zwar sehr einfach zu implemen- 
tieren, aber sie sind nicht vollständig, d.h. es gibt Constraint-Probleme, für die 
Lösungen existieren, die von local propagation nicht gefunden werden. In 
solchen Fällen wird dann in der Regel versucht, das Problem mit einer iterativen 
numerischen Methode zu lösen. Die Bedeutung dieser Ansätze ist wohl vor allem 
darin zu sehen, daß sie die Idee, Probleme durch Constraints zu beschreiben, 
einem breiteren Interessentenkreis zugänglich machten. Eine Rolle dürfte dabei 
spielen, daß Programme wie ThingLab den Constraint-Gedanken durch 
interaktive grafische Oberflächen unmittelbar visualisieren. 

Die meines Erachtens zukunftsweisendste Entwicklung zum Thema Constraints 
versucht, die "unsaubere" Anbindung von speziellen Constraint-Algorithmen an 
Programmiersprachen zu vermeiden. Die oben kurz erwähnten Algorithmen, wie 
local propagation, erfordern ja wegen ihrer Unvollständigkeit den Durchgriff auf 
die zugrundeliegende Sprache (Lisp, Smalltalk, Prolog ...), sodaß die meisten 
Programme zu einer Mischung aus (deklarativen) Constraint-Ausdrücken und 
prozeduraler Sprache werden. Das führt zu schwerer verständlichen und schlecht 
wartbaren Programmen. Eine mögliche Lösung dieses Dilemmas liegt darin, 
Sprachen zu entwerfen, die von vornherein die Idee der Problembeschreibung 
und -lösung mit Constraints beinhalten. Die langfristig interessantesten 
Bestrebungen liegen vermutlich in der gegenseitigen Annäherung der Konzepte 
Logic Programming, Functiona! Programming und Equational Programming 
(siehe z.B. Reddy 1986, Goguen u. Meseguer 1986, 0'Donnell 1985, Dershowitz 
und Plaisted 1985). Diese Aufsätze zu referieren wäre sicherlich Thema eines 
eigenen Vortrages. 

Mittelfristig halte ich zwei Versuche für aussichtsreich. Zum einen wird die 
existierende und sogar in Normung befindliche Sprache PROLOG um eine 
"Constraint-Semantik" erweitert werden. Dazu bedient man sich u.a. Ideen und 
Algorithmen aus dem OR (z.B. Simplex für lineare Gleichungssysteme). Im 
heutigen Prolog-Standard ist z.B. der Ausdruck "3*4 = 12" syntaktisch 
korrekt, erhält aber bei Auswertung den Wahrheitswert "falsch". PROLOG 
"kennt" eben keine Arithmetik oder Algebra. Somit sind zwar Gleichungen und 
Gleichungssysteme formulierbar, PROLOG "weiß aber nichts damit anzufangen". 
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Zum anderen scheinen sprachunabhängige Ansätze, Constraint-Netze 
durch Standard-Graphenalgorithmen aufzubereiten, erfolgversprechend 
(z.B. Serrano 1987). Zudem sind durch die explizite Repräsentation als Graph 
nach der Berechnung einer Lösung Erklärungen 

für den Benutzer ableitbar , wie das Ergebnis zustandekam (vgl. dazu auch 
Steele 1980). 

Ein weiterer Vorteil seines Ansatzes ist, daß sich durch eine Analyse des 
Constraint-Graphen mit Zuordnungs-Algorithmen feststellen läßt, ob ein 
"overconstrained / underconstrained problem" vorliegt. 

Die Frage, ob Constraints nun eher ein Kl- oder OR-Thema sjnd, ist letzten Endes 
rhetorischer Natur. Orientiert man sich an der Verwendung des Begriffes in 
Publikationen, so wird man vorwiegend in der Kl-Literatur fündig. Aber selbst 
damit ist der Rahmen zu eng gesteckt. Auch in der Welt der Datenbanken ist der 
Begriff geläufig. Wertet man dagegen als entscheidendes Kriterium die Frage, 
welche Lösungstechniken verwendet werden, dann stellt man fest, daß die 
Informatiker dabei sind zu entdecken, daß das OR z.T. bereits effiziente 
Methoden für spezielle Constraint-Probleme entwickelt hat. "Informatische" 
und OR-Ansätze durchdringen sich also gegenseitig. Schließlich scheint durch das 
Denken in Constraints auch bei den bearbeiteten Problemkiassen eine 
Annäherung zwischen Kl und OR stattzufinden. 

Ob die in Entwicklung befindlichen Constraint-Systeme und -Sprachen auch bei 
sehr großen Problemen von der Effizienz her gegen spezialisierte OR-Verfahren 
bestehen können, bleibt abzuwarten. 
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Abstract 

Im Zuge der Entwicklung des Fachgebiets der Künstlichen Intelligenz (KI), das sich 
im Kern mit einem verbesserten Verständnis von Begriffen wie Wissen, Intelligenz 
und Bewußtsein beschäftigt, erweist sich auf der Basis von Positionen der 
evolutionären Erkenntnistheorie die Modellienmg der umgebenden Realität als 
Schlüsselbegriff. Modellierung ist dabei ln einem sehr allgemeinen Sinne zu 
verstehen und umfaßt auf einer frühen Ebene der Entwicklung von Lebensformen 
ausschließlich Modellierungen in Form von chemisch-biologischen Strukturen, auf 
einer späteren Ebene zusätzlich Modellierimgen in Form neuronaler Netze und 
schließlich auf der begrifflichen Ebene eine Modellienmg in Form von symbolischen 
Konstruktionen, wie zum Beispiel Sprache, interpretierte Bilder oder Zeichen. Wenn 
sich die KI auch ln besonderem Maße mit einem Teilgebiet der symbolischen 
Verarbeitung von Wissen beschäftigt, insbesondere Wissen logischer oder 
relationaler Art, so zielen die zentralen Themen des Fachgebiets letztendlich doch 
auf die Integration unterschiedlichster Modellierungsformen zu leistungsfähigen 
Lösungen, wobei zumindest auf absehbare Zeit die Umsetzung auf Rechnern und 
damit eine große Nähe zu Informatikmethoden im Vordergrund steht. Der 
vorliegende Vortrag will aufzeigen, wie verschiedene Modellierirngsansätze unter- 
schiedlicher wissenschaftlicher Disziplinen in der KI Zusammenwirken und wie 
insbesondere der Modellierungsbegriff nicht nur die KI befruchtet, sondern die KI 
auch eine neue Sicht und Betonung des Modellierungsgedankens in die Wissen- 
schaft einbringt. 
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Einleitung 

Begriffe wie Wissen, Lernen, Intelligenz, Bewußtsein stellen zentrale Themen dar, 
mit denen sich das Fachgebiet der Künstlichen Intelligenz (KI) in Zusammenarbeit 
mit anderen wissenschaftlichen Disziplinen auseinandersetzt. Im vorliegenden 
Vortrag wird ausgehend von Positionen der evolutionären Erkenntnistheorie 
versucht, diese Begriffe zu präzisieren. Dies geschieht über einen erweiterten 
Modellbegriff, der als Basis für die Steuerung von Verhalten von Systemen gesehen 
wird. Der Qualitätsmaßstab für entsprechende Modelle ist evolutionstheoretischer 
Art. Die Modelle sind den unterschiedlichen Stufen des Evolutionsprozesses 
zugeordnet und insofern von teils geometrisch-stofflicher, teils neuronaler und teils 
^mbolischer Art. Sie korrespondieren zu unterschiedlichen Arten des Austauschs 
von Informationen mit der umgebenden Welt. Die in Betracht gezogenen 
wesentlichen informationstragenden Größen sind Wechselwlrkimgen auf atomarer 
und molekularer Ebene, die Gleichgewichtsverhältnisse in elektrischen Netzen und 
mathematisch-symbolhafte Kalküle. Die betreffenden Modellierirngsformen korres- 
pondieren im Evolutionsprozeß zu verschiedenen Stufen der Entwicklung, wie zum 
Beispiel Einzeller, höhere Lebewesen und Staatenbildung. Es ist dabei zu 
berücksichtigen, daß die Jeweils höheren Formen des Informationsaustausches in 
den jeweils früheren Stufen konkret realisiert werden und daß mit dem Übergang 
zu höheren Stufen in der Regel auch eine gewisse Verarmung hinsichtlich der 
spezifischen Ausdrucksmöglichkeiten verbunden ist, während andererseits die 
zimehmende Kompaktheit der Codierung effizientere Schlußfolgerungsmecha- 
nismen erlaubt. Es wird aufgezeigt, wie sich ln diesen Rahmen insbesondere die 
tiefergehenden Intelligenz- und Bewußtseinsphänomene einordnen. Ferner wird 
auch der Stellenwert der mathematischen Modelle im weitesten Sinne als Mittel zur 
Beschreibimg unserer Umwelt diskutiert; dies betrifft Gebiete wie Differential- 
gleichungssysteme, statistische Systeme, Optimierung, Entscheidungstheorie und 
so weiter. Insbesondere wird dann in diesem Umfeld erhellt, wo der wesentliche 
Beitrag der neueren Entwicklungen im Bereich der KI zu sehen ist, der 
insbesondere ln der Bereitstellung von funktionalen, logischen und relationalen 
ModelUenmgsparadlgmen auf Rechnern besteht. Mit dieser Bereitstellung ist nicht 
per se eine Erweiterung der in der Mathematik verbundenen Formalismen 
verbunden, sondern deren konsequente Umsetzimg auf immer leistungsfähigere 
Rechnersysteme. Insbesondere sind ln diesem Zusammenhang die Experten- 
systemshells zu nennen, die einerseits durch ihre spezifischen Modellierungs- 
elemente neue Bereiche praktisch zu erschließen erlauben, andererseits aber auch 
als Meta-ModelUerungs{^steme die Integration verschiedener klassischer Modellie- 
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rungsparadigmen erlauben. Damit wird es insbesondere möglich, in besserer Weise 
als bisher die kleissisch verfügbaren Techniken für Nutzer verfügbar zu machen, die 
von den betreffenden Theorien und Methoden nur vergleichsweise wenig verstehen. 
Der Rechner selbst übernimmt dabei eine Schnittstellenfunktion zwischen den 
spezifischen (internen) Modellierungssichten des Benutzers und deren Umsetzung 
in mathematische Formalismen und zugehörige rechnerinterne Modellierungs- 
formen. 



Teil I: Modellierung und Informationsverarbeitung 

Der vorliegende Vortrag geht aus von dem Begriff des Wissens über relevante Dinge 
in der Welt. Der Wissensbegrifif ersetzt in der KI zunehmend den Intelligenzbegriff, 
und zwar deshalb, weil man hofft, für den Wissensbegriff eher eine Präzisierung 
leisten zu können. Allerdings ist auch dies nicht einfach. Einen möglichen Zugang, 
der charakteristisch für die evolutionäre Erkenntnistheorie (161, (321, [331, (361, 
139], I40J, (531, 156] ist, stellt die Verfolgung des Evolutionsprozesses dar, der sich 
über lange Zeiträume in Formen und Lösungen konkretisiert und dabei bestimmtes 
Wissen festgemacht hat. In einem sehr allgemeinen Sinne kann man hier Modelle 
als den entscheidenden Begriff identifizieren, wobei Modelle sehr allgemein zu 
verstehen sind und jeden Mechanismus bezeichnen, mit dem Systeme in 
Austausch mit der umgebenden Welt verhaltensrelevante Schlüsse ableiten. Über 
die Qualität der Modelle und die Qualität der abgeleiteten Schlüsse kann nur im 
Sinne einer Überlebensfähigkeit und damit einer relativen Güte einer Modellierung 
gegenüber alternativen (konkurrierenden) Modellierungen gesprochen werden (21]. 
Der Austausch von Informationen mit der umgebenden Welt muß von den jeweils 
vorhandenen physikalischen Austauschmöglichkeiten ausgehen imd besitzt als 
Informationsaustausch jeweils nur Sinn (und ist jeweils nur bedeutungstragend) in 
bezug auf eine entsprechende Modellierung. 

Eine detaillierte Verfolgung des Evolutionsprozesses zeigt als einen wichtigen Typ 
der Modellierung zunächst eine Repräsentation über die geometrische Form (etwa 
in atomaren oder kristallinen Strukturen), später dann in molekularen Strukturen. 
Wissen ist in diesem Umfeld von der Art wie das Wissen, das ein Schlüssel über ein 
spezifisches Schloß besitzt [21], [29], [46], (47]; das Wissen ist in einer 
geometrischen Struktur abgelegt und kann zum Beispiel über (analoge) 
Kopiervorgänge vervielfältigt werden. Solches Wissen ist von entscheidender 
Bedeutung, bildet sich im Evolutionsprozeß zunehmend als Teil der genetischen 




265 



Optimierungsvorgänge heraus und ist auch heute noch eine typische Form des 
Wissens auf der molekularen bzw. der Einzellerebene. Zum Beispiel sind 
wesentliche Teile des menschlichen Immunsystems gerade so organisiert, daß bei 
Bedarf verschiedene Formen zufallsgesteuert generiert werden, bis die passende 
Form für einen "Feind” gefunden imd der "Feind" damit erkannt wird. Die passende 
Form bewirkt automatisch das Einklinken und damit das Unschädlichmachen des 
bekämpften körperfiremden Stoffes aufgrund der Wirksamkeit von Umgebungs- 
faktoren. Das Wissen ist dabei in einer Gestalt codiert und wirkt gleichzeitig als 
Sensor imd Aktor. Die entsprechenden Formen der Codierung und deren 
Verbesserungen durch den Evolutionsprozeß, die heute auch als Vorbild im Bereich 
der genetischen Algorithmen fungieren (111, (151, dauern an und sind nach wie vor 
auch eine Basis für die Ausprägung von Körpermerkmalen aller höheren Lebewesen 
(361. In diesem Sinne ist zum Beispiel der Huf eines Pferdes (in einem sehr 
allgemeinen Siime) ein grobes Modell der Steppe. Typisch für diese geometrisch- 
stofflichen Repräsentationen ist ein dazu korrespondierender Mechanismus des 
Informationsaustauschs mit der Welt, der insbesondere die eindeutigen 
Schalenpositionen in Atomen und Wechselwirkungen im molekularen Bereich zur 
Codierung nutzt. Insbesondere ist der für das Leben so entscheidende genetische 
Code inhaltlich auf dieser Ebene anzusiedeln (291, (301. 

Im weiteren Verlauf der evolutionären Entwicklung wird es dann aus Gründen der 
Arbeitsteilung und der Kombinatorik sinnvoll, das Einfangen relevanter 
Informationen über die Welt nicht mehr ausschließlich über Modifikationen der 
Form, sondern im weitesten Sinne unter Nutzung von verschaltbaren Netzwerken 
vorzunehmen. Beispielsweise kann ein Vorteil darin liegen, zu schon vorhandenen 
Formelementen nicht immer neue hinzu zu erflnden, sondern eher eine 
Manipulation und Bewegung vorhandener Formelemente auf der Basis sensorisch 
erfaßter Umweltparameter anzustreben. Die aufzunehmenden Sensorinformationen 
sind am Anfang uninterpretlert, bestehen also bei Bildern zum Beispiel aus Pixeln 
(Wahrnehmung von Photonen-BUtzen), und führen über ein elementares 
Schaltznetzwerk zu Aktionen. Hier findet sich die Basis für neuronale Netzlösungen 
als höhere Repräsentationsschicht von Wissen [31. Als Beispiel hierfür betrachte 
man in einer frühen Entwicklungsphase die Reaktion eines Lebewesens auf die 
Beobachtung eines noch nicht interpretierbaren dunklen, sich verstärkenden 
Flecks, zum Beispiel ln Form von eigenen Körperbewegimgen. Wieder wirkt der 
Evolutionsprozeß dahingehend, daß dann, wenn sich entsprechende Reaktionen 
auf einen solchen Fleck als w^ntlich erweisen, die entsprechend agierenden 
Lebewesen tendenziell eher überleben. Damit wird in einer solchen Reaktion auf 
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bestimmte geometrische Pixelmuster Begrifflichkeit codiert, etwa als "Freßfeind", 
wenn es sinnvoll ist, sich zu entfernen, oder als "Beute", wenn es sinnvoll ist, sich 
zu nähern. 

Es ist an dieser Stelle wieder zu beachten, daß auch die konkrete Realisierung 
derartiger neuronaler Netze wieder auf molekularen bzw. atomaren Prozessen 
beruht, daß aber aufgrund der erfolgten Aggregationsprozesse konzeptionell neue 
Operatoren hinzukommen. Waren es ln der frühen Phase insbesondere atomare 
und molekulare Anziehungskräfte, die wirksam werden, so spielen Jetzt verstärkt 
elektrische Gleichgewichte als neue Operatoren eine große Rolle. In der 
Ausprägung und Fortentwicklung neuronaler Netze [3], (61, (55 ] kommt es im 
weiteren zu einem immer komplexeren Wechselspiel zwischen Sensorinformationen 
und daraus resultierenden Verhaltensweisen, wobei zunehmend Meta-Lernregeln 
eines relativ einfachen Typs, wie sie heute auf dem Gebiet der neuronalen Netze 
nachempfunden werden (31, (6|, ln der Lage waren, bessere Anpassungen zu 
bewerkstelligen. Man kann dabei auf der neuronalen Ebene ln dem Sinne von einer 
Modellierimg sprechen, als Klassen von Signalen auf der Eingangsseite zu 
bestimmten Situationen korrespondieren, die dann mit bestimmten passenden 
Aktionen beantwortet werden. Diese Art der Modellierimg läßt sich als eine Black- 
Box-Modellierung verstehen und ermöglicht zugehörige Formen des statistischen 
Black-Box-Lemens. Das Wissen steckt dabei in Synapsen, in Verbindungen und 
deren Intensität. Es ist von außen nicht direkt erschließbar, sondern nur in der 
gleichzeitigen Wechselwlrkimg vieler aktivierter Knoten realisierbar. 

Von dem neuronalen Paradigma ausgehend ergibt sich als entwicklungmäßig letzte 
Stufe schließlich das, was als Symbolverarbeltimg bzw. als die symbolische Ebene 
der Repräsentation und Verarbeitung von Wissen bezeichnet wird. Diese Ebene 
bildet einen wesentlichen Teil des Modellierungspotentials aller höheren Lebewesen 
und besteht im Kern darin, daß sich entsprechende Systeme bei Vorliegen 
bestimmter neuronaler Erregungsmuster, etwa dem Abbild eines Baumes in der 
Außenwelt, intern darüber Rechenschaft ablegen, daß ein bestimmtes Objekt, 
nämlich zum Beispiel ein Baum, vorliegt (17). Diese vorgeschaltete Klassifikations- 
leistung, die zum Beispiel Voraussetzimg der Sprachfähigkeit ist, erlaubt dann eine 
sehr kompakte Codierung, etwa als Ikon, als Wort oder als mathematisches 
Symbol. Die zugehörige Abstraktionsleistimg, also die Zuordmmg eines neuronalen 
Erregungsmusters zu einem kompakt repräsentierbaren Begriff, ist eine aufwendige 
kognitive Leistung, die allerdings in einer geisteswissenschaftlichen Tradition 
vielleicht deshalb nicht voll gewürdigt wurde, weil sie von vielen Lebewesen 
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beherrscht wird [171. Es ist hierbei zu beachten, daß es sich in einer natürlichen 
Umgebung um eine Modellierung handelt, die zum Beispiel einen Baum als 
kompaktes Objekt aus Stämmen und Blättern sieht, während andererseits die 
moderne ModelUenmg eines Baumes in der Teilchen-Physik im wesentlichen aus 
leerem Raum besteht. Dies ist nicht überraschend, da von Natur aus solche 
Modellierungsformen bevorzugt werden, die Aspekte erfassen, die für das Überleben 
in einer natürlichen Umwelt relevant sind, nicht aber die darunterliegenden, für 
unsere natürliche Sensorik viel zu feinen quantentheoretischen Phänomene. Auch 
diese modernen quantentheoretischen Beschreibungen haben dabei keinen 
absoluten Wahrheitscharakter, sondern stellen nur die feinste aktuell bekannte 
und verwandte Form der Modellierung dar, die eine weitgehend konsistente 
Erklärung der uns experimentell bekannten Phänomene zuläßt. Die dabei nach wie 
vor bestehenden grundsätzlichen Probleme, etwa hinsichtlich der Natur des Zufalls 
[71, sollen hier nicht erörtert werden, besitzen aber unter Umständen eine 
fundamentale Bedeutung zum Beispiel hinsichtlich der Möglichkeit menschlicher 
Freiheit [30]. 

In der hier eingenommenen Sicht der evolutionären Erkenntnistheorie [18], [32], 
[331, [361, [39], [53], die sich an Überlebensfähigkeit als wissensakkumulierenden 
Mechanismus orientiert, ist die besohriebene natürliche menschliche Modellierung 
seiner natürlichen Umgebung angemessen. Sie ist ähnlich der Modellierung, die 
Primaten und viele andere höhere Lebensformen vornehmen. Auch bei anderen 
Lebewesen erlaubt diese Form der Modellierung bereits eine Manipulation der 
entsprechenden Begriffe ln rudimentärer Form, so wie es beim Menschen in der 
Fortentwicklung wissenschaftlicher Theorien, wo neue Begriffe zimächst nur mit- 
wahrgenommen, erahnt und als Bilder von Beispielen oder Bündel von Bildern 
verwaltet werden, ebenfalls geschieht. In diesem Sinne korrespondieren zu unserer 
Fähigkeit, einen Baum mit dem Wort "Baum” zu belegen und damit eine 
tieferllegende neuronal erfolgte Modellierung auf einer höheren Ebene zu 
repräsentieren, entsprechende Fähigkeiten bei den Primaten und anderen höheren 
Lebensformen. Es ist interessant, daß diese bei Tieren so breit entwickelten 
Leistungen, die heute zunehmend als intelligent erkannt werden und die ln 
signifikantem Umfang zu Fähigkeiten neuronaler ModelUenmgsschlchten korres- 
pondieren, von Rechnern auf einer s)onbolischen Ebene (bis heute) nur sehr 
begrenzt vorgenommen werden können. 

Mit der beschriebenen Abstraktion und dem damit erfolgten Übergang auf eine 
symbolische Ebene geht es verstärkt um die Manipulation derartiger Symbole. 
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Symbole können, wie oben schon erwähnt, interpretierte Bilder (Ikonen), Sprache 
oder Bezeichner in mathematischen Kalkülen sein, die dann in unterschiedlicher 
Weise verarbeitet, zueinander in Bezlehimg gesetzt und manipuliert werden. Der 
Mensch ist mehr als alle anderen Lebensformen in der Lage, durch entsprechende 
Abstraktionen auf diesen Symbolen Begriffe zu verarbeiten, zu manipulieren, zu 
komplexen Systemen zusammenzuführen, weiter zu abstrahieren und immer neuen 
Verwendungsformen zuzuführen. Die Höhepunkte dieser Möglichkeiten werden 
zum Beispiel in den mathematischen Modellierungstheorien wie Logik, Entschei- 
dungstheorie, Wahrscheinlichkeitstheorie, Spieltheorie, Theorie der Differential- 
gleichungen und so weiter sichtbar IlOJ, (161, [21], [27], [38], [42], [47], [54]. Mit der 
Theorie der Berechenbarkeit gelang dabei sogar die Beschreibung dessen, was 
algorithmisch in universeller Weise auswertbar ist [4], [13]. (Hinweis: Hierbei ist 
allerdings von Zeit- und Speicherplatzproblemen zu abstrahieren und ferner zu 
beachten, daß die partielle Berechnung universell nicht lösbarer Aufgaben den 
eigentlichen Gegenstand zum Beispiel der mathematischen Wissenschaften 
darstellt [1]). Hier ist es in der Spätphase der Evolution dem Menschen gelungen, 
eine signifikante Weiterentwicklung zu schaffen, die es ihm gestattet, sich 
hinsichtlich seiner Fähigkeiten explosionsartig fortzuentwickeln. Dadurch wird ein 
an sich nicht so großer Unterschied zu den höheren Tierformen, wie den Primaten, 
exponentiell potenziert, und damit werden die Voraussetzungen geschaffen, die die 
kulturelle Hochentwicklung des Menschen, wie wir sie heute beobachten, 
überhaupt erst ermöglichen. Im Rahmen dieses Prozesses wurde die Menschheit als 
Ganzes zum eigentlichen Träger der Intelligenz auf dieser Welt und ist im Potential 
bereits weit über die Leistungsmöglichkeit der einzelnen Individuen hinaus- 
gewachsen. Die Potenzierungsmöglichkelten erinnern dabei an die erhöhte 
Modellierungslähigkeit [18], [19] etwa des Ameisenstaates gegenüber der einzelnen 
Ameise (zum Beispiel die Schaffung eines "Bildes einer Küche mit diversen 
Süßigkeiten" auf der Ebene des Ameisenstaates, codiert über Duftspuren der 
einzelnen Ameisen). Sie bedeuten Insbesondere, daß kognitive BIAS-Phänomene 
des Menschen [9], [21] nicht zum Maßstab für intelligentes Verhalten gemacht 
werden sollten (Probleme bei der konsistenten Verarbeitung von Präferenzen und 
Wahrscheinlichkeiten oder analog bei der Abschätzung mechanischer Flugbahnen 
über große Distanzen). Die Menschheit hat hierbei als Ganzes in vielen Fragen 
längst die evolutionstheoretisch nachvollziehbaren natürlichen Limitationen des 
menschlichen Informationsverarbeitungsapparates durch wissenschaftliche Ent- 
wicklungen, Ausbildungssysteme und intensive Kommunikationsleistungen über- 
wimden [18], [41], [52], [56]. 
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Führt man die beschriebenen Überlegungen zusammen, so läßt sich Intelligenz 
verstehen als die Fähigkeit, situationsabhängig geeignete Modellrepräsentationen 
und Inferenzen zu erzeugen und zu nutzen, wobei diese in diesem beschriebenen 
Sinne weit über das symbolische Paradigma hinausgehen. Bewußtsein ist ln 
diesem Umfeld gekoppelt an das Vorhandensein einer ganzen Hierarchie von 
Eigenmodellen von sich sdlber [191, (281, 1301, (361, während Wissensbasierung die 
explizite Bereitstellung und Ausfüllung geeigneter Modelle und Inferenztechniken 
bezeichnet. Lernen ist ln diesem Zusammenhang die Fähigkeit, verfügbare Modelle 
im Kontext bestimmter Variationsmöglichkeiten fortzuentwickeln und anzupassen. 
Dabei ist bereits auf der symbolischen Ebene zumindest zwischen (statischem) 
Lernen ln vorgegebenen Begrlffsi^stemen, Lernen unter Einschluß standard- 
mäßiger Veränderungen von Begriffssystemen und Lernen in Form komplexer 
Begriffsverändenmgen (Analogie, genetische Verfahren) zu unterscheiden [11, (21), 
[341, 1351, [481. Interessante Modellierungen betreffen im Umfeld der Nutzung der 
Rechnertechnologie nicht nur die jeweiligen Anwendungsbereiche, sondern 
Insbesondere auch die Modellierung von Systembenutzern, die Modellierung von 
Dialogprozessen sowie Selbstmodelle von Systemen [211. Als Hauptthese läßt sich 
hier zusammenfassen: 

Das Charakteristikum der Intelligenz ist die Fähigkeit zur Manipulation 
von Modellen. Aufbauend auf Positionen der evolutionären Erkenntnis- 
theorle stellen Modelle der umgebenden Welt den zentralen Erkenntnis- 
zugang dar. 

Sprache ist das mächtigste Instrument zur Verwaltung, Schaffung, Veränderung 
und Benutzung von Modellen und sprachlicher Austausch ein Instrument zur 
wechselseitigen Kommunikation von Modellen der umgebenden Realität. Modelle, 
die sprachlich verarbeitet werden, sind dabei auf einer hohen Komplexitätsstufe 
angesiedelt. 

Faßt man all dies zusammen, so erhält man eine Hierarchie von Modellierungs- 
möglichkeiten, deren Beherrschimg möglicherweise mit dem Begriff Intelligenz und 
damit zusammenhängenden Begriffen identifiziert werden kann. Im Gegensatz zu 
dem engen Kl-Paradigma der Symbol-Manipulation sind auch die anderen 
genannten Modellbereiche (geometrische Strukturen, neuronale Netze) mit 
eigenständigen Operatoren, wie zum Beispiel dem elektrischen Gleichgewicht in 
komplexen Netzen, von Interesse. Diese Operatoren sind bis heute in vernünftiger 
Zeit nicht in genereller Weise digitalisiert realisierbar. 
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Damit kommt gegenüber der primär digitalen Perspektive der heutigen 
Informationsverarbeitung ein analoges Prinzip ins Spiel, das allem Anschein nach 
für die kognitive Leistungsfähigkeit des Menschen wesentlich ist und das von 
Kritikern der zum Teil engen heutigen Ansätze im Bereich der Künstlichen 
Intelligenz immer wieder als notwendig herausgestellt wird 15). Die Betonung dieses 
Aspekts scheint auch dort nicht unbedeutend zu sein, wo es "nur" um den Umgang 
mit sprachlicher Information geht, derm auch bei sprachlicher Information referiert 
der Mensch in wesentlichen Bereichen auf vorsprachliche (subsymbolische) 
Repräsentationen, die ihrer Natur nach Körpererfahrungen darstellen. 

Dies gilt insbesondere dann, wenn von Bewußtseinsprozessen und von 
Eigenschaften und Gefühlen des Menschen die Rede ist, wenn also auf Begriffe 
referiert wird, die unmittelbar mit eigenen Körpererfahrungen Zusammenhängen. 
Begriffskomplexe wie Haß, Liebe, Glück, Zufriedenheit, Hunger, Scham usw. sind 
beim Menschen auf einer tieferen Ebene, sei es in unmittelbar materieller 
Repräsentation, sei es in Form neuronaler Modelle, vorhanden. Auch bereits vor der 
Erfindung der Sprache waren entsprechende Zustände da und im Verhalten 
wirksam. Das sind sie bei uns wie auch beispielsweise bei höheren Primaten und 
vielen anderen Lebensformen. Eine Interessante Frage ist dabei, inwieweit 
Intelligenz und Emotionalität von Systemen einander in einem bestimmten Umfang 
sogar bedingen (5 1 ]. 

Die Bewußtmachung dieser tieferliegenden Prozesse, beispielsweise auch in der 
pi^choana^schen Forschung, stellt ln der hier vertretenen Perspektive Einblicke 
in die eigene Innere Modellierung des Menschen dar. Dabei werden auf einer 
höheren Ebene (nämlich der sprachlichen Ebene) Aspekte mit Begriffen belegt, die 
vorher bereits da sind und mit Hilfe unseres biologisch-chemischen Apparates auch 
unmittelbar (Jedoch vorbewußt) interpretiert werden. Wenn nun Menschen 
untereinander mit sprachlichen Mitteln über diese Aspekte kommunizieren, 
können sie sich deshalb verständigen, weil sie im Prinzip ähnliche 
Körpererfahrungen haben. 

Es scheint allerdings unmöglich zu sein, auf einer rein sprachlichen Ebene (also 
gegenüber einem RechnerjSfystem oder auch einem hypothetischen Wesen von 
einem anderen Stern) die Natur dieser Körpererfahrungen auf einer rein verbalen 
Ebene zu kommunizieren. Hier kommen potentiell andere Modellierungsformen ins 
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Spiel; die rein sprachliche und, allgemeiner, die Ebene der Symbolverarbeitung, 
scheint dafür als nicht ausreichend [23], [44], [58], [59]. 

Insgesamt schließt sich somit der Kreis. Modellierung ist die eigentliche Basis 
intelligenter Leistimgen. Daher ist die Modellierung der Welt eine der zentralen 
Aufgaben, die zu leisten ist, wenn man intelligente Systeme realisieren wUl. Dabei 
ist eine rechnergemäße Sammlung von Wissen in Form logischer oder relationaler 
Zusammenhänge zwischen Elementen (Begriffen) in sehr großen Wissensbanken 
ebenso wichtig wie eine rechnergemäße Integration vorhandener mathematischer 
Modellierungsparadigmen. Im Hinblick auf dieses Ziel bilden Sprache und 
naturwissenschaftliche Weltmodellierung denjenigen Bereich einer Modellrepräsen- 
tation, der wohl am ehesten mit Methoden der Symbolmanipulation und daher mit 
den heutigen Ansätzen der Künstlichen Intelligenz beherrschbar erscheint. Dabei 
sind allerdings bestimmte Grenzen, etwa hinsichtlich der Einbeziehung von 
Körpererfahrungen, erkennbar. 

Neuartige methodische Herausforderungen eines stark interdisziplinären 
Charakters für die Zukunft resultieren dabei nicht zuletzt aus der Entwicklung von 
Systemen (sogenannte Modell- und Methodenbanksysteme), die die intelligente 
Nutzung der vorhandenen imterschledllchen kalkülhaften Auswertimgsmethoden 
zu realisieren gestatten [2], [8], [14], [21], [22], [25], [26], [47]. Nach heutiger 
Technologie wird es unter anderem darum gehen, die bekannten KI-Modellierungs- 
mechanismen als Meta-Ebene zu nutzen, um auf die klassischen Modellierungs- 
techniken und zugehörige Algorithmen zuzugreifen. Je nach Problemkreis wird 
dabei zusätzlich der Übergang zu tiefergehenden Beschreibungsebenen, also zum 
Beispiel zu einer neuronalen Ebene als Filterstation für Sensorinformationen oder 
auch als Assoziationsbereich zur Findung vollständig neuer Begriffe, genutzt 
werden müssen. An einer davorliegenden Eingangsstufe wird schließlich verstärkt 
auch die Einbeziehung intelligenter Werkstoffe eine zunehmend wichtige Rolle 
einnehmen. 



n. Wissensrepräsentation tind Inferenzsysteme 

Prinzipielle Grundlagen und Ansatzpunkte für eine explizite Repräsentation von 
Wissen, tmd damit für eine Modellierung von Gegebenheiten, sind in den 
einschlägigen wissenschaftlichen Disziplinen vorhanden und teils auch 
anwendungsorientiert aufbereitet. Zur Strukturierung, Klassifikation und 
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Behandlung von großen (dynamischen) Fallunterscheidungen (einem in seiner 
großen Bedeutung erst in der Jüngsten Zeit voll gewürdigten Modellierungs- 
element), aber auch zur Realisierung von Inferenzen und zum Aneinanderreihen 
von elementaren Schlußfolgerungen ("wenn ... - dann ...-Regeln”) steht die Logik als 
maßgebliche Disziplin zur Verfügung |21I, [371, |48], 149], [57]. Abhängigkeiten 
werden zum Beispiel über Funktionen, Relationen, Graphen, semantische Netze, 
Tabellen, Produktionregeln, Frames und vergleichbare Strukturen beschrieben, 
während Methoden der Statistik, Stochastik und Evidenztheorie [31], [38], [50] be- 
stimmte Formen der (objektiven) Unsicherheit bzw. Vagheit von Größen zu 
modellieren gestatten. Inferenzen ln diesem Kontext können zum Beispiel 
statistische Zusammenhänge oder "verborgene” Parameter umfassen. Erhebliche 
praktische Probleme betreffen jeweils die Amalgamierung von Verarbeitungs- 
methoden für die verschiedenen Repräsentationsmethoden. 

Methoden der Entscheidungstheorie [9], [10], [20], [24], [54] erlauben eine 
"angenäherte” Modellierung von Benutzersichten bzw. -Präferenzen, während zum 
Beispiel mathematische Hilfsmittel zur Behandlung von Optimierungsmodellen 
oder Differentialgleichungssystemen efOziente und aussageiählge Inferenzen über 
reale Gegebenheiten erlauben, die mittels derartiger Modelle beschrieben werden 
können. Die auf diese Weise erschließbare Kompetenz und Einsichtsleistung in 
reale Gegebenheiten geht dabei weit über die intuitiven Fähigkeiten hinaus, die der 
Mensch von Natur aus zur Lösung entsprechender Aufgabenstellungen mitbringt. 

Es ist dabei bemerkenswert, daß vor allem die Nutzung verschiedenartiger logischer 
Beschreibungsformalismen in den letzten Jahren den entscheidenden Durchbruch 
gebracht hat, weil auf diese Welse erstmals die Verwaltung und rasche 
Erschließung umfangreicher Wissensbasen als Hilfsmittel zur Beschreibung von 
umfangreichen, dynamischen Fallunterscheidungen mit jeweils spezifischen Regel- 
anwendungen und Methodenaufrufen möglich wurde. Pionier^steme der 
angedeuteten Art waren zum Beispiel DENDRAL (Spektralanalyse chemischer 
Substanzen), MYCIN (Medizinische Diagnose), XCON (Rechnerkonfigurierung) sowie 
im Lernbereich AM (ein System zur Begriffserzeugung im Bereich der elementaren 
Mengenlehre und Zahlentheorie [34]). 

Geht man etwas tiefer in die einzelnen Tools, die im Rahmen des Gebiets der KI (im 
engeren Sinne) in den letzten Jahrzehnten bereitgestellt wurden, so sind es von der 
Logik ausgehend insbesondere zunächst logische Programmiersprachen, wie zum 
Beispiel PROLOG, die es erlauben, einen Teil der in der Aussagenlogik bzw. 
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Prädikatenlogik auftretenden Formeln und Ausdrücke (insbesondere die 
sogenannten Hornklauseln) efilzient zu verarbeiten (48], (49]. Aussagenlogische 
Hornklauseln erlauben die Modellierung bestimmter Anwendungen, die dadurch 
gekennzeichnet sind, daß das benötigte Wissen im wesentlichen über Formeln 
beschrieben wird, die besagen, daß Jeweils aus einer Reihe von Voraussetzungen 
eine bestimmte Aussage (nicht aber etwaige Disjunktionen oder die Negation von 
Aussagen) gefolgert werden kann. Durch geeignete Verkettung derartiger Aussagen 
(vorwärts /rückwärts), damit letztlich durch Anwendung des logischen Operators 
"modus ponens” oder daraus abgeleiteter Varianten, wie zum Beispiel der 
sogenannten "Resolution", können komplexere Schlußfolgerungen aus entspre- 
chenden Formeln gezogen werden. So kann zum Beispiel die Frage beantwortet 
werden, ob eine bestimmte Aussage aus den vorhandenen Formeln und 
Basisaussagen gefolgert werden kann, bzw. auch eine Auflistung aller möglichen 
Variablenbelegimgen vorgenommen werden, die zu der gewünschten Aussage 
führen. Wie schon auigedeutet, ist in einem gewissen Umfang eine Verarbeitung von 
Quantiflzienmgen über Variablen mit bestimmten Eigenschaften möglich, für die 
bestimmte Aussagen folgen. Ein wichtiges methodisches Hilfsmittel ist hierbei zum 
Beispiel die Unifikation (die eine ähnliche Funktion wie -Zuweisungen in anderen 
Programmiersprachen hat), basierend auf der Identifikation des Vorliegens 
bestimmter "Muster". Wichtige Randbedlngimg für die Festlegung der durch eine 
logische Programmiersprache akzeptierbaren Formeln sind die resultierenden 
algorithmischen Schwierigkeiten, wenn geeignete Einschränkungen nicht 
vorgenommen werden (49]. 

Wie die Sprache PROLOG im Rahmen des Paradigmas der Aussagen- und 
Prädikatenlogik und der dort bekannten algorithmischen Auswertungsverfahren 
entwickelt wurde, so ist eine andere im Bereich der KI wichtige Sprache, nämlich 
LISP, eine partielle Umsetzung der funktionalen Sichtweise der Programmierung, ln 
der Programme imd Daten wie Funktionen (in mathematischen Kalkülen) 
behandelt werden. In LISP ist der Unterschied zwischen Programmen und Daten 
weitgehend aufgehoben und somit ein für die KI wie für Intelligenzphänomene 
insgesamt wichtiges Prinzip, nämlich die Anwendung von Formeln und Funktionen 
auf sich selber, in bequemer Weise softwaretechnisch realisierbar. LISP ist deshalb 
auch bis heute eine für bestimmte Aufgaben der KI besonders leistungsfähige 
Sprache. 

Ein weiteres konsequent verwendetes Prinzip ist dasjenige der Objektorientierung, 
in welchem aus Gründen der Beschreibimgsökonomle Interessierende Größen als 
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Objekte (zum Beispiel ln Verbindung mit der Verwendimg von Datenstrukturen wie 
Frames) abgelegt werden. In Objekten können die entsprechenden Datenstrukturen 
und die darauf operierenden Algorithmen geeignet verkapselt werden. Die Objekt- 
orlenüenmg bietet sich dann dazu an, Klassenhierarchien und die Vererbung von 
Eigenschaften als Mittel der Wissensstrukturierung zu nutzen (zum Beispiel ln der 
Spezlallslerungshlerarchle Lebewesen-Tier- Warmblüter-Säugetler-Pferd usw.), bei 
der generelle Eigenschaften, zugehörige Methoden, Normalsltuatlonen und 
Stereotypen Immer an eine möglichst allgemeine Klasse angebimden werden. Dabei 
bildet der Informationsaustausch zwischen Objekten das Programmierparadigma. 
Sprachen wie SMALLTALK 80 stehen für diesen in der Informatik heute immer 
stärker verbreiteten Ansatz. Praktische Probleme betreffen die Organisation der 
algorithmischen Abarbeitung von Objekthierarchien, also zum Beispiel das 
Auffinden von Objekten und die Entscheidung darüber, wann man damit beginnt, 
auf speziellen Stufen benötigte algorithmische Hilfsmittel auf abstrakteren Stufen 
zu suchen bzw. abzuleiten. Die prinzipiellen Probleme sind insbesondere dann 
groß, wenn man multiple Vererbung zuläßt, also Methoden und Wissen von 
verschiedenen, zueinander unvergleichbaren Verallgemeinerungen her abgeleitet 
werden können. Die Frage ist dann zum Beispiel, in welcher Reihenfolge man die 
betreffenden unvergleichbaren Abstraktionen durchlaufen soll. Neben der reinen 
Vererbungshierarchie spielen dann oft auch weitere Strukturierungsansätze eine 
Rolle. Für viele Anwendungen (zum Beispiel in der Maschinendiagnose) wesentlich 
ist die sogenannte Part-of-Bezlehung, die die Möglichkeit der (wiederum 
hierarchisch durchführbaren) Zerlegung großer Einheiten in Teilkomponenten 
bietet. Dabei kann die Zerlegung über die Part-of-Beziehimg geeignet verschränkt 
werden mit der oben schon beschriebenen allgemeinen Vererbungsmethodik (481. 

Trotz der beschriebenen Vielfalt von Darstellungs- und Verarbeitungsmöglichkeiten 
hat sich ln den letzten Jahren in entsprechenden Anwendungen oft gezeigt, daß die 
Strukturierungsmöglichkeiten über zum Beispiel geeignete Logikkalküle, Funktio- 
nen oder Objekthierarchien dann, wenn Programmierung und Darstellung elegant 
und überschaubar bleiben sollen, von einer für viele Anwendungen zu schwachen 
Ausdrucksmächtigkeit ist, man also eine Modellierung der jeweiligen Anwendung 
nicht in angemessener, das heißt kognitiv adäquater und im Hinblick auf die 
Auswertung efflzienter Weise vornehmen kann. In diesen Situationen ist 
insbesondere häufig der Bedarf deutlich geworden, Restriktionen (constraints) 
unterschiedlicher Art einbeziehen zu können, also zum Beispiel Intervall- 
beschränkungen für bestimmte Werte. Aus klassischer Sicht entspricht dies der 
Suche nach Lösungen oder nach der Belegung logischer Formeln mit Werten, die 
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zugleich bestimmten Nebenbedingungen genügen, also zulässig im Sinne einer 
bestimmten Problembeschreibung sind. Entsprechende Inferenzsysteme, die 
schrittweise Regeln verketten, müssen ln dieser Situation eine Berücksichtigung 
und Verknüpfung (Propagierung) derartiger Nebenbedingungen vornehmen und 
dazu in der Lage sein, gegebenenfalls festzustellen, daß entsprechende Lösungen 
nicht existieren. Der entsprechende algorithmische Prozeß, der weitgehend den 
üblichen Ableitimgen entspricht, wird in der Literatur oft als "Constraint 
Propagation” bezeichnet. 

Zur Bewältigung aufwendiger algorithmischer Situationen der beschriebenen Art 
wird es häufig. Insbesondere bei umfangreichen Problemen, notwendig, aufgrund 
von Vorkenntnissen oder Vermutungen bzw. im Rahmen von Fallunterscheidungen 
bestimmte, im Prinzip noch variable Werte, zunächst einmal mit wahrscheinlich 
vernünftigen Werten (default-Werten) zu belegen. Es kann dann in solchen 
Situationen Vorkommen, daß sich durch nachträglich hinzukommende Informa- 
tionen solche früheren Annahmen als falsch erweisen, also revidiert werden 
müssen. Da solche Situationen in der klassischen Logik natürlich nicht auftreten, 
weil dort nicht mit Vermutungen, sondern nur mit sicheren Aussagen (bezogen auf 
das Modell) gearbeitet wird, treten hier sogenannte Nicht-Monotonie-Phänomene 
auf, aufgrund derer man manchmal (etwas verwirrend) von nicht- monotonen 
Logiken spricht. De facto handelt es sich darum, daß versuchsweise bestimmte 
Werte besetzt und bei erweiterter Information dann unter Umständen auch wieder 
geändert werden. Die Konsistenthaltung, automatische Prüfung, Anpassung und 
Veränderung entsprechender Werte tmd Manipulationen bearbeitet man mit 
algorithmischen Systemen, die als Assumptlon- bzw. Justillcatlon-based Truth 
Malntenance-Systeme (TMS) bezeichnet werden. Sie sind konzeptionell unter 
anderem ein Instrument zur Verarbeitimg kombinatorischer Problemaspekte. 

Schließlich betreffen im Bereich der KI besonders komplexe Kalküle sogenannte 
Uncertainty-Mechanismen, mit denen versucht wird, Quanüflzlerimgen der 
Unsicherheit von Aussagen und Regeln geeignet in entsprechende Aussagen über 
abgeleitete Resultate oder Regeln zu transformieren. Hier hat es ausgehend vom 
MYCIN-System viele Ansätze gegeben, bei denen versucht wurde, durch 
entsprechende Formelmanipulationen zu interpretierbaren Sicherheitsbewertungen 
für abgeleitete Aussagen zu kommen. Es ist allerdings heute ersichtlich, daß die 
Grundlagenfundierung entsprechender Kalküle bisher bei weitem nicht ausreicht, 
insbesondere dann nicht, wenn stochastische Abhängigkeitsphänomene, die bei 
abgeleiteten Formeln häufig sind, hinzukommen. Diese Fragestellungen werden 
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weltweit mit erheblichem Forschungsaufwand untersucht, zum Beispiel im Umfeld 
der sogenannten Bvldenztheorie [31], [36], [50]. 

Betrachtet man die verschiedenen aufgeführten Repräsentations- und Modellie- 
rungsformalismen im engeren Arbeitsbereich der KI, dann geht es um zweierlei; 
Zum einen werden häufig Varianten von Beschreibungskalkülen, die in der 
Mathematik ächon immer genutzt wurden, graduell für den Rechnereinsatz 
operationalislert und damit für eine erweiterte Rechnernutzimg verfügbar gemacht. 
Zum anderen wird dabei als typische neuere Entwicklung eine besondere Betonung 
auf das Ziel gel^, für Wissen (bezüglich einer bestimmten "Rahmentheorie'') 
deklarative Ablagemöglichkelten zu schaffen und entsprechende Wissensinhalte 
von Einsichten über die Abarbeitung entsprechenden Wissens softwaremäßig zu 
trennen. Auf diese Welse wird eine neue Unterstützungsschicht für Anwender 
geschaffen, die ein näher an üblichen Beschreibungsmechanismen der Sprache 
oder Mathematik angelehntes Formulieren von Anwendungsproblemen erlaubt. Für 
die praktische Nutzung und Umsetzung im Bereich der wissensbasierten Systeme 
ist dann der entscheidende Beitrag der KI in den letzten Jahren die Bereitstellung 
komplexer Algorithmen, sogenannter Inferenzj^steme, die in der Lage sind, ln 
entsprechender Form deklarativ abgelegte Inhalte einer jeweiligen Anwendung 
geeignet zu verarbeiten und zu Aussagen zu kommen, die entweder in Lösungen 
bestehen, die die entsprechenden Nebenbedingungen erfüllen, oder die Feststellung 
betreffen, daß entsprechende Lösungen nicht existieren. Im letztgenannten Fall 
werden häufig Möglichkeiten der Abhilfe (zum Beispiel der Problem-Relaxlerung) 
bzw. andere nützliche Hinweise angeboten. Als Folge der weitgehenden bzw. 
angemessenen Trennung' der deklarativen imd prozeduralen Aspekte geht dabei die 
eigentliche Abarbeitungskontrolle im Programm immer stärker auf die entspre- 
chenden komplexen Programmsysteme (Inferenzsysteme) über, die ihrerseits, wie 
bereits angedeutet, aufwendige (traditionelle) algorithmische Lösungen darstellen 
und das Herzstück der entsprechenden Entwicklungssysteme, die heute auf dem 
Markt verfügbar sind, ausmachen. 

Natürlich resultieren aus dieser weitgehenden Separierung der verschiedenen 
Wissensinhalte, imd in der Regel auch der damit befaßten Personen, erneut 
wesentliche Vereinfachtmgen für den Anwender, allerdings häufig auf Kosten 
erhöhter benötigter Rechenzelt und Speicherkapazität. Die Entwicklung bedeutet 
zugleich auch einen bestimmten Verlust der Kontrolle der Programmierer und 
Entwickler über die speziellen Abläufe und Ergebnisse der Programmsysteme, 
insbesondere dann, wenn die entsprechenden Abarbeitungssysteme aus einer 
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Vielzahl möglicher Lösungen schließlich immer nur irgendeine Lösung anbieten, 
wobei normativ keine Basis besteht, die angebotene Lösimg im Verhältnis zu 
anderen Lösimgen geeignet zu bewerten [21]. Es ist aber anzuerkennen, daß trotz 
dieser Schwierigkeiten enorme Softwareengineering-Leistungen erbracht wurden 
und nun komplexe Systeme bereitstehen, die zumindest für entsprechend einfache 
Anwendungen die Situation wesentlich vereinfachen. Entscheidende Hilfsmittel 
sind dabei die entsprechenden Entwicklimgs^steme, die teilweise die oben 
genannten verschiedenen Ansätze wie Logikprogrammierung, funktionale Program- 
mierimg, Objektorientierung, Datenstrukturen wie Frames, Hornklauseln und 
verschiedene Zerlegungsprinzipien, wie zum Beispiel die übliche Vererbung oder die 
"Part-of'-Beziehungen, sowie schließlich auch Verarbeitungsmöglichkeiten für 
Constralnts und Komponenten für Truth-Malntenance und Uncertalnty-Handling 
in sich vereinigen. Zu den komplexeren Tools gehören zum Beispiel das bei der 
GMD entwickelte System BABYLON und das System KEE der Firma IntelUCorp. 

Faßt man insgesamt die aktuelle Situation in diesem Bereich der Methoden- 
entwicklungen in der Künstlichen Intelligenz zusammen, so kann man feststellen, 
daß heute vom Grundlagenaspekt her wesentliche Elemente für umfassende 
Modellierungs- und Inferenzlelstimgen vorhanden sind. Es gibt aber grundsätzliche 
methodische Probleme, die insbesondere die EfQzlenz von Auswertungen betreffen 
(zum Beispiel gibt es bis heute keinen Compiler für die Sprache KL-ONE) und die 
unter Umständen die oben schon genannten prinzipiellen Grenzen [5] im Vergleich 
zur Leistungsfähigkeit intelligenter biologischer Systeme bedingen. Die Grenzen der 
Effizienz und Leistungsfähigkeit haben in vielen Anwendungen, insbesondere je 
näher man an Realzeltfragen kommt, oft dazu geführt, daß Experten^steme nur 
begrenzt genutzt werden konnten. Der Einsatz dieser Technik war wesentlich 
erfolgreicher bei nicht zeitkritischen Fragestellimgen von kognitiv eher einfacher 
Natur. 



III. Stand ausgewählter Anwendungen und Ausblick 

Aufgrimd der gegebenen Hinweise erkennt man das Wesen von Wissen, Intelligenz 
und Wissensverarbeitung in einer Hierarchie von ModelUenmgsfählgkelten. 
hinsichtlich derer das engere Kl-Paradigma der Symbolmanipulation die oberste 
Schicht der Verarbeltimg darstellt. Dieser Bereich der Symbolmanipulation ist weit 
zu fassen und umfaßt zumindest formale Kalküle, Interpretierte Bilder und Sprache 
als Repräsentationsform. Im Bereich sprachlicher Informationen ist dabei der 
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Übergang zu neuronalen bzw. noch darunterliegenden Repräsentationsformen 
insbesondere in den Bereichen fließend, in denen Körpererfahrungen eine Rolle 
spielen (44). Im Bereich der Künstlichen Intelligenz (371, (481, (571 versucht man, 
entsprechende Modellierungen nachzubilden. Dabei ist es durchaus denkbar, daß 
das Fehlen analoger Komponenten in den üblichen Verarbeitungsmechanismen 
(und damit die Nichtverwendung starker, in der Natur vorhandener Operatoren) 
prinzipielle Grenzen der Modellierbarkeit in heutigen Rechnern bezeichnen, die das 
Erreichen bekannter biologischer Leistungen durch entsprechende Systemlösungen 
ausschließen (51. Dies läßt sich heute nicht abschließend beurteilen. Wesentlich ist 
aber, daß man bis heute auch im Bereich der Modellierung mittels digitaler 
Systeme die große Breite und Leistungsfähigkeit der entsprechenden, biologisch 
bereits realisierten, Symbolverarbeitungsprozesse häufig noch nicht erreicht hat. 
Die in der Künstlichen Intelligenz und im mathematischen Umfeld vorhandenen 
Repräsentations- imd Inferenzformen sind von ihrer Leistungsfähigkeit her noch 
begrenzt, erlauben aber immerhin schon interessante Anwendungen in Bereichen 
wie Expertensysteme, Sprachver stehen, Computer sehen, Robotik und so weiter. 
Zum Stand auf diesen Gebieten der Künstlichen Intelligenz seien folgende kurze 
Hinweise gegeben: 

EXPERTENSYSTEME 

Expertenj^steme bewähren sich in kognitiv einfachen Situationen (zum Beispiel 
Konflguratlon), bei "Artefakten" (wenn "Common Sense" keine Rolle spielt) sowie 
zum Beispiel auch bei gesellschaftlich akzeptierter eingeschränkter Verantwor- 
tungsübernahme (Diagnose). Hingegen sind die Leistungsgrenzen heutiger Ansätze 
mit zunehmender Unsicherheit von Daten und komplexen Benutzerpräferenzen 
sowie am Rande des Jeweiligen Kompetenzbereiches unübersehbar. Insbesondere 
im dispositiven Bereich helfen diese Ansätze bisher nicht wirklich weiter [12], (421, 
(431, [481, (571. 

SPRACHVERSTEHEN 

Gewisse Erfolge im Verständnis geschriebener (mehr) und gesprochener (weniger) 
Sprache sind zu verzeichnen. So bringen Übersetzungssysteme im technischen 
Bereich (Dokumentationen, Handbücher usw.) mittlerweile eine bis zu 90 %ige 
Arbeitsreduktion. Anders ist die Situation bei freiem Text. Aktuelle Entwicklungen 
betreffen Modellierungsnotwendigkeiten [23], [44], (58), [59]. So nutzt man 
Partialmodelle des Gegenstandsbereichs bzw. von Handlimgsaspekten zum Beispiel 
in Form von Beschreibimgen stereot}^r Abläufe bestimmter Handlungen (wie etwa 
Restaurantbesuche) oder bei neueren Entwicklungen in der Diskurs-Theorie (wenn 
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man eine Modellierung von zeitlichen Phänomenen in Betracht zieht und 
insbesondere die kombinatorische Natur der Zeitbeziehungen nutzt, um bestimmte 
Annahmen einer ModeUlerung zu falsifizieren) sowie schließlich im Bereich der 
sogenannten Sprech-Akt-Theorie, die eine Modellierung des Ablaufs von Diskursen 
darstellt. 

Als generelle Herausforderung wird heute, wie in anderen Gebieten auch, die 
Notwendigkeit der Arbeit an 'Vollständigen'' Weltmodellen deutlich. Ein 
wesentliches Beispiel dieser Art ist die Entwicklung von CYC in Austin (Texas) bei 
MCC 135): der erste konsistente Versuch einer weitgehenden ModeUlerung des 
AUtagswissens in Form einer Wissensrepräsentation. Hier ist D. Lenat - aufbauend 
auf seine früheren bahnbrechenden Beiträge zum Begriffslernen und zum 
Verständnis von Analogieschlüssen im Rahmen der Entwicklung des AM-Systems 
(341 - mit einem Team von zehn Wissenschaftlern in einem Zehnjahresprojekt 
damit beschäftigt, auf der Basis heutiger Wissensbasierungsmethoden unter Aus- 
nutzung verschiedener Varianten von klassischen Inferenztechniken eine 
zumindest teilweise Ablage des vorhandenen AUtagswissens zu versuchen. Das 
Projekt wird seit einigen Jahren bearbeitet und entwickelt sich bisher planmäßig im 
Rahmen der ursprüngUchen Zeitvorgaben. 

RECHNERSEHEN 

Einfache Anwendimgen in der Fertigung, wie etwa Punktschweißaufgaben oder die 
Identifikation bestimmter Objekte, Szenarien oder Abläufe aus einer begrenzten 
Menge sowie (eingeschränkt) zum Beispiel auch das Lesen von Adressen auf 
Datenträgern, gelingen mittlerweUe. Ein Rechner-Sehen und -Verstehen relativ 
aUgemelner Szenen scheitert Jedoch bis heute an den ungelösten Problemen einer 
(lokalen) WeltmodeUienmg. Dies güt auch für andere Sensorarten (UltraschaU, 
InfrarotUcht). 

ROBOTIK 

In den Anwendungen werden zunehmend komplexe Fertigungsaufgaben und auch 
die fahrerlose Bewegung von TeUen durch Systeme übernommen. Für die Zukunft 
steht die Betonung der Autonomiefragen an. Hierzu müssen Systeme über 
umfangreichere Modelle ihrer Umgebung, ihrer Aufgaben und letztlich auch über 
sich selber verfügen und auch dazu befähigt werden, diese selbst zu verändern. 
Sicherlich stellt der Bereich der autonomen Systeme langfristig die größte 
Herausforderung für die KI dar, und die hier erreichten Lösungen werden unter 
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Umständen einen erheblichen Einfluß auf die Philosophie und Erkenntnistheorie 
und letztlich auch auf das Bild des Menschen von sich selber haben. 

PROJEKTARBEITEN AM FAW (ULM), vgl. (451 

Auf der Basis der erwähnten Einsichten bearbeitet zum Beispiel dais Forschungs- 
institut für anwendungsorientierte Wissensverarbeitung (FAW) in Ulm eine Vielzahl 
konkreter Aufgabenstellungen ln den Bereichen CIM, Büroautomation, Umweltir\for- 
mationssysteme, Assistenzsysteme und Verteiltes Ressourcenmanagement Hierbei 
werden und wurden bisher die folgenden Projekte bearbeitet: 

(a) CIM 

CAD/ KI (Wissensbasierte Unterstützung der Konstruktion) 

CAP (Computer-alded Plannlng); abgeschlossen Dezember 1989 
GENOA (Generierung und Optimierung von Arbeitsplänen) 

KWEST (Wissensbasierte Werkstattsteuerung) 

AIDA (Automatische Instandhaltung und Diagnose im Automobilbereich) 

(b) Büroautomation 

FOS (Flexible Bürosysteme) 

OSSY (Organisatlons-Support-System) 

MHS (Materlalhandhabungsi^steme); abgeschlossen im September 1989 

(c) Umweltiriformationssysteme 

ZEUS (Kompetenzinformation und Methodenintegration) 

RESEDA (Wissensbasierte Auswertung von Rasterbilddaten) 

WANDA (Wissensbasierte Meßdateninterpretation in der Umweltanalytik) 

(d) Assistenzsysteme 

IKARUS (Grenzverlauf zwischen Fahrer -Fahrzeug-Kommunikation und systemauto- 
nomen Eingriffen) 

NAUDA (Natürlichsprachlicher Zugang zu relationalen Datenbanken) 

PROMOTEX (Prolog Motor Expert System); abgeschlossen im März 1990; Weiter- 
führung im Anwendungsgebiet CAE 
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(e) Verteiltes Ressourcenmanagement 

WINHEDA (Wissensbasierter und natürlichsprachlicher Zugriff auf verteilte hetero- 
gene Datenbanken) 

SESAM (Entscheidungsunterstützung bei Scheduling-Problemen) 

ALIAS (Lernen in neuronalen Netzen) 



IV. Bewertung bestehender Potentiale 

Versucht man heute eine zusammenhängende Bewertung der mittels KI-Methoden 
erschlossenen neuen Modellierungsmöglichkeiten, dann zeigen sich insbesondere 
solche Anwendungen, für die ein eher flaches Wissen typisch ist, also beispiels- 
weise die Verwaltung sehr großer Regelsysteme imd die Einbeziehung von 
Vererbungsprozessen über relativ flachen Hierarchien. Damit läßt sich bereits eine 
Vielzahl anspruchsvoller, teils sehr personalintensiver Anwendungen abdecken, 
zum Beispiel dann, wenn Verfahrensvorschriften, Verwaltungsvorschriften, Kompa- 
tibilitäten oder Klassifikationsvorgaben (Diagnose, Konfiguration) einzuhalten sind 
oder wenn eine Vorgangsverfolgung (zum Beispiel im Zusammenhang mit 
Kredltgewähnmg oder PoUcenbestlmmimg im Versicherungsbereich) vorgenommen 
werden soll bzw. wenn eine Vielzahl von Verwaltungsaufgaben, die in der Verteilung 
und Bearbeitimg von Dokumenten bestehen, unterstützt werden soll. Es zeigt sich 
immer mehr, daß die entsprechenden KI-Lösungsbeiträge gerade auch in der 
Übernahme kognitiv vergleichsweise einfacher, aber für das Operieren von 
Systemen extrem wichtiger Überbrückungsfimktionen bestehen können. Als 
Beispiel sei hier auf intelligente Netzwerklösungen oder auch auf die intelligente 
(für den Benutzer extrem vereinfachte) Nutzung von aufwendigen technischen 
Hilfsmitteln in Bürobereichen verwiesen. Dies wird ln Zukunft beispielsweise für 
die Telefonvermittlung und beim Computer-Integrated Telephonlng eine große Rolle 
spielen. Für einen flächendeckenden Einsatz von Methoden der Wlssensverar- 
beitimg, vor allen Dingen für Aufgaben in der Robotik wie im Sprachverstehen, gibt 
es bis heute allerdings einen prinzipiellen Engpaß, und zwar die Notwendigkeit der 
immer wieder neuen Aufarbeitung der entsprechenden Wissensbasen. In diesem 
Bereich gibt es mittlerweile Internationale Anstrengungen, zu universell einsetz- 
baren Lösungen zu konunen. Zu nennen ist vor allen Dingen das oben bereits 
erwähnte CYC-ProJekt am MCC in Texas, das auf die Modellierung des 
Alltagswissens unserer Zivilisation ln Form einiger Millionen elementarer, 
taxonomle-verknüpfter Wissensstatements abzielt. Mit Fortschritten in diesem 
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Bereich wäre zumindest hinsichtlich relativ flacher Wissensmodellierungen ein 
gewisser Abschluß zu erreichen. Auf der anderen Seite steht als großes Programm 
die generelle Einbindung der klassischen Methoden der angewandten Mathematik, 
etwa in der Optimierung, Statistik, Entscheidungstheorie und bei Differentialglei- 
chungssystemen in den Rahmen von wissensverarbeitenden Systemen nach wie vor 
aus. Bisher gibt es in diesem Bereich nur spezifische Entwicklungen, wie etwa 
statistische Expertensysteme, und auch zunehmend Vorarbeiten hin zu integrierten 
Methoden- und Modellbanken. Methoden- und Modellbanken imd deren problem- 
spezifisch adäquate Nutzung sind für die Zukunft eine der zentralen Heraus- 
forderungen und werden die Zusammenarbeit und letztlich auch die Integration 
zwischen KI-Ansätzen und den klassischen ModelUerimgsansätzen beflügeln. Die 
KI wird dabei immer bessere Schnittstellensysteme zur Verfügung stellen können, 
um mit deren Hilfe die klassischen Modellierungstechniken immer größeren 
Kreisen von Benutzern adäquat zur Verfügimg zu stellen und diese zugleich in 
einer Weise verwalten und fortschreiben zu köimen, die über heutige 
Realisierungsmöglichkeiten weit hinausgeht. Dies wird zu neuen Formen des 
Wissenstransfers führen und endlich den großen Schatz an Modellierungs- und 
Methodenwissen umzusetzen gestatten, den Generationen von Forschern erarbeitet 
haben, der aber heute noch zu großen Teilen weitgehend ungenutzt in Journalen 
dem Vergessen anheim gegeben wird. 

Neben dieser Weiterverfolgung der technischen Aspekte sollte schließlich - gerade 
unter Aspekten einer richtig verstandenen Technikfolgenforschung - auch das 
geisteswissenschaftliche und philosophische Potential dieser modernen Forschun- 
gen im Bereich der KI und der Modellierirngstheorien nicht unerwähnt bleiben. Es 
spricht sehr vieles dafür, daß wesentliche Klärungen hinsichtlich der für das 
Fragen des Menschen nach sich selbst so wichtigen Begriffe wie Wissen, Lernen, 
Intelligenz, Bewußtsein und Freiheit möglich werden und daß diese Begriffe durch 
die erarbeiteten Systemlösungen insbesondere einen anderen Charakter erfahren 
und dadurch eine neue Form des Verstehens erlauben werden. Der Mensch wird 
dabei sehr viel mehr über sich selbst, aber auch über die ihn bestimmenden 
Zwänge verstehen lernen. Er wird den prägenden Einfluß des heute schon 
dominierenden intelligenten Übersystems Menschheit anders zu würdigen wissen 
und ln diesem Erkennen leichter die notwendigen Schritte auch hinsichtlich der 
unter Umständen notwendigen Einschränkungen von Individualrechten (zum 
Beispiel Bevölkerungswachstum) und Konsummöglichkelten bei sich selber 
akzeptieren, die wahrscheinlich unausweichlich sind, wenn Menschen auf dieser 
Erde langfristig und in global fairem Umgang miteinander überleben wollen. Der KI 
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kommt in diesem Erkenntnisprozeß eine Schlüsselrolle zu. Darüber hinaus kann 
sie über die Förderimg von automatischen Wissensverarbeitungsprozessen, zum 
Beispiel als Teil einer weitergehenden Automatisierimg von Arbeitsprozessen oder 
auch als Mittel des Wissenstransfers in die Staaten der Dritten Welt, auch 
wesentlich dazu beitragen, eine Realteierung der notwendigen gesellschaftlichen 
und wirtschaftlichen Veränderungen in einer sozial akzeptablen Weise zu 
erleichtern. 
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